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像 谷 歌 一 样 部 姥 自 己 的 应 用 ,这 是 很 多 软件 工程 师 的 梦想 。 
Docker 的 目 标 是 圆 很 多 人 的 梦 。 自 从 InfoQ 推 出 Docker 系 列 文章 ， 
作为 操作 系统 课程 教师 的 我 一 直 在 学 习 并 关注 Docker 的 东 壮 成 长 。 


当 我 发 现 这 上 面 刊登 的 “Docker 源 码 分 析 " 系 列 文章 的 作者 居然 是 
我 们 课程 组 的 研究 生 助 教 孙 宏 亮 时 ， 惊 喜之 情 溢于言表 。 宏 亮 对 
Docker 的 理解 十 分 深刻 ， 他 本 人 是 Docker 的 积极 拥护 者 、 倡 导 者 和 
页 献 者 。 他 在 研究 生 毕 业 以 后 投身 人 了 创业 公司 DaoCloud , 去 为 
Docker 的 梦想 开创 美好 的 未 来 。 


最 近 ，, 我 又 欣喜 地 发 现 ， 这 系列 文章 以 及 后 续 章节 即将 正式 出 版 
成 书 , 有 机 会 同 更 多 的 Docker 用 户 、 开 发 者 、 学 习 者 见面 。 本 书 通 过 
分 析 解 读 Docker 源 码 ， 让 读者 了 解 Docker 的 内 部 结构 和 实现 ， 以 便 
更 好 地 使 用 Docker。 该 书 的 内 容 组 织 深 入 浅 出 ， 表 述 准 确 到 位 ， 有 大 
量 流程 图 和 代码 片段 帮助 读者 理解 Docker 各 个 功能 模块 的 流程 ， 是 学 
习 Docker 开 源 系统 的 恨 师 益 友 。 


一 一 寿 黎 旦 ， 浙 江 大 学 计算 机 学 院 教授 


近年 来 ，Docker 迅 速 风 靡 了 云 计 算 世 界 ， 但 是 专门 针对 Docker 
的 技术 实现 进行 深入 分 析 的 文章 却 相 对 较 少 。 这 一 方面 由 于 Docker 技 


术 变 化 很 快 ， 源 码 分 析 很 快 会 跟 不 上 版 本 发 展 ; 男 一 方面 ， 对 源 代码 
的 解析 ， 需 要 对 整个 Docker 设 计 具 备 全 局 的 视角 ,才能 深入 浅 出 地 找 
到 源码 中 的 脉络 。 


宏 亮 的 这 本 《 Docker 源 码 分 析 》 ， 恰 如 其 时 的 出 现 ， 弥 补 了 这 个 
空白 ， 对 于 希望 参与 到 Docker 社 区 、 参 与 代码 贡献 或 构建 自己 的 
Docker 应 用 环境 的 读者 来 说 ,应 是 一 本 案头 必 备 书籍。 


一 一 王 尺 宇 ,《 Linux 中国 》 创 始 人 


在 崇尚 源码 至 上 的 工程 师 文 化 里 ， 文 档 介 绍 、 发 布 会 材料 都 是 爷 
白 的 , 唯 有 研读 源码 ， 才 能 深刻 理解 软件 育 后 的 原理 。 与 所 有 其 他 软 
件 一 样 ， 读 源码 并 不 是 学 习 Docker 最 快 的 途径 ， 但 是 如 果 有 人 通读 源 
码 后 给 出 了 详细 分 析 ， 你 就 可 以 轻松 地 站 在 巨人 的 肩膀 上 。 

很 高 兴 看 到 国内 这 么 快 就 出 版 源码 分 析 的 书籍 。 对 于 所 有 想 在 
Docker 方 面 进 阶 和 想 普 升 为 高 端 用 户 的 读者 ， 都 值得 阅读 本 书 ， 也 希 
望 通过 《 Docker 源 码 分 析 》 一 书 ， 可 以 诞生 更 多 的 社区 页 献 者 ,共同 
推动 Docker 的 发 展 。 


一 一 黄强 ， 华 为 Docker Committer 


值得 自豪 的 是 ， 就 在 Docker 血 勃发 展 之 际 ， 第 一 本 详尽 剖析 
Docker 源 码 的 著作 出 自 国 人 之 手 。 


本 书 在 每 章 宏观 的 流程 梳理 背后 都 伴随 有 更 加 细致 深入 的 源码 分 
析 。 无 论 读者 是 只 想 了 解 使 用 Docker , 还 是 抱 着 深入 理解 Docker 并 
参与 社区 开发 、 二 次 开发 的 心态 ， 本 书 都 值得 一 读 。 


一 一 胡 科 平 ， 华为 Docker Committer 


这 本 书 从 源码 的 角度 对 Docker 的 实现 原理 进行 了 深入 的 探讨 和 细 
腻 的 讲解 ， 将 当前 热门 的 容 闫 技术 的 背后 机 理 讲 解 得 深入 浅 出 明白 透 
彻 。 无 论 是 Docker 的 用 户 还 是 开发 者 ， 通 过 阅读 本 书 都 可 以 对 
Docker 有 更 深刻 的 理解 ， 能 够 更 好 地 使 用 或 者 开发 Docker。 


一 一 雷 继 某 ， 华 为 Docker Committer 


Docke 中 经 是 一 个 成 长 2 年 时 间 的 云 计 算 技术 , 它 正 在 以 惊人 的 
速度 在 全 球 范围 内 扩张 自己 的 “ 续 士 "。 我 作为 Docker 中 国 区 的 开发 
者 ， 非常 希望 能 看 下 有 一 本 书 详细 地 告诉 我 ，Docker 的 每 一 个 细节 是 
如 何 实现 的 。 所 以 当 我 在 InfoQ 上 看 到 宏 亮 的 "Docker 源 码 分 析 " 专 栏 
时 眼前 一 之 。 今 天 ， 它 终于 汇编 成 书 摆 在 你 我 的 眼前 。 我 希望 你 能 在 
这 本 书 上 学 到 更 多 Docker 技 术 的 精髓 思想 ， 在 实战 Docker 技 术 时 可 
以 运用 自如 ! 


一 一 肖 德 时 ， 数 人 科技 CTO 


我 家 里 的 书柜 中 至 今 仍 然 保留 着 一 本 4 Linux 内 核 完 全 注释 》 ， 
它 伴随 我 很 长 一 段 时 间 ， 使 我 受益 菲 浅 。10 年 之 后 ， 当 我 拿 到 宏 亮 的 
《 ”Docker 源 代码 分 析 》 草 稿 ,昨日 又 重 现 。 这 本 书 无 论 是 对 学 习 
Docker , 还 是 掌握 Go 语言 , 都 是 非常 好 的 一 手 资源。 雷锋 不 常 有 ， 
大 家 要 支持 | 


一 一 赵 鹏 ,VisualOps 创 始 人 


序 


三 年 前 ， 我 在 VMware 负责 Cloud Foundry 这 一 款 开 源 PaaS 产 
品 在 中 国 的 开发 者 社区 和 生态 系统 建设 工作 。 当 时 关于 Cloud 
Foundry 的 中 文 文档 非常 少 ， 更 不 用 说 有 深度 的 技术 干货 了 “， 所 以 当 
CSDN 上 出 现 了 一 个 专门 从 底层 模块 和 源码 的 角度 ， 对 Cloud 
Foundry 做 深度 剖析 的 系列 博客 文章 时 ， 一 下 子 就 引起 了 我 的 注意 。 


经 过 一 番 “ 人 肉 搜索 ”, 我 非常 惊奇 的 发 现 ， 这 一 系列 干货 的 作者 
孙 宏 亮 ,竟然 是 浙江 大 学 计算 系 的 一 年 级 研究 生 。 当 时 ，VMware 跟 
浙江 大 学 在 Cloud Foundry 方 面 有 比较 深入 的 合作 ,浙大 计算 机 系 的 
SEL 实 验 室 ,投入 了 精锐 的 师资 力量 ， 从 事 分 布 式 系统 和 新 一 代 Paas 
的 研究 工作 。 宏 亮 初 入 浙江 大 学 ， 就 在 这 样 的 氛围 下 开始 了 他 的 研究 
生 求 学 生涯 ， 应当 说 是 非常 幸运 的 。 


宏 亮 在 CSDN 上 的 系列 文章 ， 主 打 “ 源 码 分 析 ”, 这 正 是 当时 开源 
社区 内 比较 缺少 的 内 容 。 提 笔 写 “源码 分 析 ”, 需要 一 定 的 勇气 , 阅读 
源码 需要 耗 禹 大 量 的 精力 ， 需 要 从 数 十 万 行 代码 中 整理 出 清晰 的 取 
辑 ， 从 中 抽 丝 挨 音 、 概 括 精华 ， 这 是 一 份 非常 圣 昔 的 工作 。 而 且 ，, 分 
析 源 码 也 需要 一 些 “ 挑 战 权 威 " 的 精神 ， 不 仅仅 是 简单 的 代码 解析 ,更 
需要 提炼 出 自己 的 观点 ,甚至 敢于 发 现 和 纠正 一 些 已 有 的 问题 。 


在 源码 分 析 方 面 ， 宏 亮 充 分 体现 了 “初生 牛犊 不 怕 虎 ”的 精神 ， 非 
常 详 细 地 剖析 了 当时 Cloud Foundry 的 几 个 主要 模块 ， 条 理 清 晰 ， 技 
术 分 析 准 确 到 位 。 宏 之 这 一 系列 文章 帮助 了 包括 一 线 互联 网 公司 在 内 
的 许多 企业 了 解 、 认 识 和 最 终 使 用 Cloud Foundry， 宏 亮 也 借 此 奠定 
了 他 在 PaaS 社 区 的 “江湖 地 位 ”。 


从 去 年 开始 ，Docker 的 热潮 开始 波及 中 国 开发 者 社区 。 我 有 幸 跟 
宏 亮 一 起 在 CSDN 主 办 的 第 一 届 Container 技 术 大 会 上 发 表 联合 主题 
演讲 ， 向 来 宾 介 绍 Cloud Foundry 内 部 的 容 右 技术 实现 ,以 及 对 
Docker 的 一 些 展望 。 那 次 大 会 是 一 个 很 重要 的 里 程 碑 , 在 那 之 后 , 宏 
亮 开 始 深入 研究 Docker 的 底层 实现 ， 并 在 InfoQ 连 载 “Docker 源 码 分 
析 ” 系 列 文章 。 


对 PaaS 平 台 的 研究 越 深 入 ， 越 能 够 发 现 和 体会 Docker 对 开发 和 
运 维 的 价值 。 如 果 说 当初 的 Cloud Foundry 模 块 和 源码 分 析 文 章 ， 是 
读 研 期 间 的 学 习 笔 记 ， 那 这 次 宏 亮 的 ( Docker 源 码 分 析 》 ， 则 是 一 个 
经 过 了 深思 熟 虑 、 系 统 性 、 结 构 化 的 工作 。Docker 开 源 项 目 发 展 速度 
非常 快 ， 这 次 在 文章 连载 内 容 的 基础 上 出 书 ， 为 了 保证 内 容 的 准确 性 
和 时 效 性 ， 宏 亮 补充 了 大 量 Docker 最 新 项 目 的 内 容 ， 特 别 是 对 
Swarm、Machine 和 Compose 这 三 个 模块 的 开发 进展 做 了 紧密 的 追 


中 。 


这 是 一 本 从 架构 和 代码 角度 讲解 Docker 底 层 实 现 的 技术 图 书 ,我 
从 连载 第 一 篇 开始 就 对 这 个 系列 的 文章 保持 了 紧密 的 关注 , 也 目睹 了 
宏 亮 在 后 期 整理 加 工 成 书 过 程 中 的 六 勤 努力 。 在 《 Docker 源 码 分 析 》 
成 书 付 样 出 版 之 际 ， 非 常 拉 运 ， 能 够 为 宏 亮 与 着 一 篇 推荐 序 。 这 本 书 
非常 适合 以 下 三 类 读者 学 习 和 阅读 。 


:希望 以 Docker 容 器 交付 软件 的 程序 员 。 


Docker 是 未 来 互联 网 软件 的 交付 件 ， 这 件 事 随 着 OCP 标 准 的 制 
定 ,正在 逐渐 成 为 事实 。 程 序 员 和 运 维 工程 师 都 需要 了 解 Docker 的 工 
作 方 式 ， 尤 其 是 Docker 镜 像 的 结构 ， 软 件 通过 Dockerfile 打 包 时 的 优 
化 方式 等 ， 这 些 内 容 在 本 书 中 都 有 非常 详细 的 阐述 。 


-Docker 化 云 计算 平台 的 建设 者 和 维护 者 。 


Docker 公 司 在 今年 的 全 球 开发 者 大 会 上 提出 了 “Production 
Ready" 的 口号 ,有 越 来 越 多 的 互联 网 公司 和 传统 企业 末 用 Docker 来 
构建 开发 、 测 试 和 运 维 平台 。Docker 在 网 络 、 存 储 、 安 全 等 领域 的 细 
节 ，, 是 平台 建设 者 和 维护 者 必须 深入 了 解 的 部 分 ， 这 些 领域 还 在 不 断 
变化 , 新 的 项 目 也 层出不穷 ， 但 本 书 对 网 络 、 存 储 和 安全 的 基本 知识 
和 概念 ， 做 了 非常 清晰 的 介绍 ,也 深入 到 了 底层 实现 的 代码 。 


.Go 语言 程序 员 。 


即使 不 在 项 目 中 使 用 Docker , 本 书 也 能 够 为 Go 语言 程序 员 带 来 
帮助 。Docker 项 目 中 大 量 采 用 了 Go 语言 ,尤其 是 在 处 理 并 发 场景 
时 ，Docker 对 Go 语言 的 运用 可 谓 出 神 入 化 。 本 书 可 以 帮助 Go 语言 程 
序 员 亲身 体验 特大 型 项 目 中 Go 语言 的 威力 ， 以 及 实战 场景 中 Golang 
模式 和 功能 的 用 法 。 


最 后 ， 预 祝 安 亮 在 Docker 的 学 习 和 工作 中 再 创 佳 绩 ， 也 希望 读者 
可 以 从 本 书 收 获知 识 ， 开 闭 腿 界 。 


喻 勇 


2015 年 7 月 13 晶 


Docker 是 什么 


Docker 从 2013 年 证 生 ， 短 短 两 年 时 间 束 在 全 球 IT 技 术 圈 内 迅速 
走红 ， 实 乃 技术 圈 内 不 可 包 视 的 一 阵 飓风 。 然 而 ，Docker 是 什么 ， 
Docker 带 来 了 什么 ? 


Docker 官 方 如 此 描述 Docker : “Build , Ship ,Run.An open 
platform for distributed applications for developers and 
sysadmins”。 换 言 之 ,Docker 为 开发 者 与 系统 管理 者 提供 了 分 布 式 
应 用 的 开放 平台 ， 从 而 可 以 便捷 地 构建 、 迁 移 与 运行 分 布 式 应 用 .。 


多 年 来 ， IT 行业 中 开发 与 运 维 一 直 是 两 个 界限 清晰 的 词 。 开 发 工 
程 师 专门 从 事 软件 的 开发 工作 ， 最 终 交 付 软件 代码 ; 运 维 工程 师 则 部 
著 前 者 交付 的 软件 ， 并 接管 软件 的 运行 与 管理 。 然 而 ,在 长 时 间 的 实 
践 过 程 中 ， 开 发 与 运 维 分 离 的 方式 难免 存在 疾病 ， 两 者 职责 的 过 分 清 
晰 导致 软件 效率 的 降低 。 随 着 分 布 式 系统 的 流行 ， 系 统 规模 越 来 越 
大 ， 软 件 越 来 越 复 杂 ， 系 统 环境 配置 暴露 的 问题 层出不穷 。 究 其 缘 
由 ， 还 是 因为 开发 人 员 缺 少 软件 运行 环境 的 认 知 ,而 运 维 人 员 对 软件 
逻辑 所 知 甚 少 。 在 这 样 的 背景 下 ，DevOps 横 空 出 世 ， 提 倡 开发 与 运 
维 不 可 分 割 ， 协 调 并 进 。 


Docker 无 疑 是 DevOps 大 潮 中 最 具 实 践 价值 的 不 二 法 宝 。 
Docker 从 Linux 内 核 的 角度 出 发 ， 属 于 轻 量 级 虚拟 化 技术 ， 有 人 能力 秒 
级 提供 应 用 隔离 环境 ， 完 成 云 计 算 时 代 分 布 式 应 用 的 第 一 需求 “ 隔 
离 "。 另 外 ，Docker 的 镜像 技术 利用 联合 文件 系统 的 优势 ， 自 下 至 上 
打包 系统 软件 、 系 统 环境 以 及 软件 程序 ,将 运行 环境 与 应 用 程序 灵活 
地 结合 ， 快 速 运行 Docker 化 的 应 用 程序 。 同 时 ， 可 读 性 极 强 的 
Dockerfile， 极 大 地 简化 镜像 的 复杂 性 ， 并 为 镜像 的 转移 与 重新 构建 
提供 了 可 能 性 。 


Docker 提 供 轻 便 的 资源 分 配方 式 ， 解 决 应 用 运行 与 系统 环境 的 依 
赖 ， 弥合 应 用 跨 节点 迁移 的 鸿沟 ， 种 种 特性 都 表明 Docker 几 乎 就 是 
为 “ 云 计算 "而 生 的 。 如 今 ，Docker 社 区 不 断 扩大 并 健康 发 展 ， 多 家 
国际 IT 巨头 也 纷纷 宣布 支持 Docker , 这 一 切 更 是 让 全 球 IT 人 士 对 
Docker 的 未 来 充满 信心 。 


本 书 的 内 容 


本 书 是 一 本 引导 读者 了 解 Docker 实 现 原 理 的 技术 普及 书 。 笔 者 一 
直 坚 信 ， 了 解 软 件 或 者 系统 最 直接 、 最 透彻 的 方式 就 是 研读 它们 的 源 
码 . “源码 即 文档 "也 是 鼓励 开发 者 能 更 多 地 从 源码 的 角度 去 学 习 软件 
或 系统 的 本 质 。 


本 书 的 内 容 主要 集中 于 3 个 部 分 : Docker 的 架构 ，Docker 的 模 
块 ，Docker 的 三 驾 马 车 Swarm、Machine 以 及 Compose。 


第 一 部 分 ， 主 要 从 宏观 的 角度 和 读者 一 起 领略 Docker 的 架构 设 
计 ， 并 初步 介绍 梁 构 中 各 模块 的 职责 。 


第 二 部 分 是 本 书 的 主体 部 分 ， 主 要 针对 Docker 中 多 个 重要 的 模块 
进行 具体 深入 分 析 , 包括 : Docker Client、Docker Daemon、 
Docker Server、Docker 网 络 、Docker 镜 像 、Docker 容 器 等 。 读 
者 可 以 发 现 ，Docker 的 模块 之 间 妩 合 度 非常 低 ， 很 适合 循序 渐进 ， 层 
层 深入 。 第 2 章 至 第 8 章 主 要 从 Docker 软 件 的 架构 入 手 ， 勾勒 骨架 ; 
第 9 章 至 第 11 章 重点 讨论 Docker 镜 像 技 术 ， 夯实 基础 ; 第 12 章 至 第 
14 章 则 进一步 分 析 Docker 容 莫 的 始末 ， 阐 述 本 质 。 


第 三 部 分 介绍 Docker 生 态 三 驾 马 车 Swarm、Machine、 
Compose。Docker 拥 有 强大 的 单机 能 力 ， 三 驾 马 车 可 以 很 好 地 补充 
Docker 的 跨 主机 能 力 以 及 部 效能 力 。 读 者 可 以 通过 第 15 章 至 第 17 章 
感受 Docker 生 仿 圈 中 其 他 功能 强大 的 软件 。 


希望 本 书 能 够 让 读者 最 大 化 地 感受 Docker 的 神奇 与 魅力 。 


关于 勘误 


由 于 时 间 与 水 平 都 比较 有 限 ， 因 此 本 书 难 免 会 存在 一 些 线 漏 和 错 
误 。 如 果 读 者 发 现 了 问题 ， 请 及 时 与 我 联系 。 我 也 会 在 本 书后 续 的 版 
本 中 加 以 改正 。 我 的 邮箱 是 : allen.sun@daocloud.io。 我 非常 希望 
和 大 家 一 起 学 习 与 讨论 Docker , 并 共同 推动 Docker 在 社区 的 发 展 。 


致谢 


最 后 ， 向 本 书 编写 过 程 中 给 予 我 巨大 帮助 的 人 们 表示 最 诚挚 的 感 
谢 。 感 谢 我 的 父母 ， 没 有 他 们 的 鼓励 和 支持 ， 此 书 不 可 能 在 如 此 短 的 
时 间 内 完成 。 感 谢 我 的 母校 浙江 大 学 以 及 SEL 实 验 室 的 老师 与 同学 
们 ， 是 他 们 在 我 求学 过 程 中 给 予 无 私 的 指引 与 帮助 。 感 谢 我 的 同事 能 
中 祥 ， 是 他 在 本 书 编写 过 程 中 提出 了 很 多 宝 中 的 建议 ,尤其 在 
Machine 和 Compose 部 分 。 感 谢 我 的 同事 喻 勇 和 冯 钊 ， 他 们 为 本 书 
的 编写 做 了 很 多 沟通 与 协调 工作 。 最 后 ， 还 要 感谢 华章 公司 的 编辑 
们 ， 她 们 认真 细致 的 工作 ， 使 本 书 以 完美 的 形式 展现 给 各 位 读者 。 


孙 宏 亮 


2015 年 6 月 


第 1 章 ”Docker 架 构 
1.1 引言 


Docker 是 Linux 平 台 上 的 一 款 轻 量 级 虚拟 化 容 右 的 管理 引擎 。 在 
全 球 范围 内 ，Docker 还 是 一 个 开源 项 目 ， 整 个 项 目 基于 Go 语言 开 
发 ,代码 托管 于 GitHub 网 站 上 ,并 遵从 Apache 2.0 协 议 。 目前 ， 
Docker 可 以 帮助 用 户 在 容 希 内 部 快速 自动 化 部 署 应用， 并 利用 Linux 
内 核 特 性 命名 空间 ( namespaces) 及 控制 组 ( cgroups) 等 为 容 怖 
提供 隔离 的 运行 环境 。Docker 借 助 操作 系统 层 的 虚拟 化 实现 资源 的 隔 
离 ， 因 此 Docker 容 器 在 运行 时 与 虚拟 机 ( VM) 的 运行 有 很 大 的 区 
别 ，Docker 容 厂 与 宿主 机 共享 同一 个 操作 系统 ， 不 会 有 额外 的 操作 系 
统 开销 。 这 样 的 优势 很 明显 ， 因 而 大 大 提高 了 资源 利用 率 ， 并 且 提 升 
了 IO 等 方面 的 性 能 。 


众多 新 针 的 特性 以 及 项 目 本 身 的 开放 性 ， 导 致 Docker 在 不 到 两 年 
的 时 间 里 迅速 获得 了 诸多 厂商 的 青睐 ， 其 中 更 是 包括 Google、 
Microsoft、VMware 等 行业 领航 者 。Google 在 2014 年 6 月 推出 了 
Kubernetes ,宣布 支持 Docker 容 器 的 调度 管理 ,而 2014 年 8 月 
Microsoft 则 宣布 Azure 上 支持 Kubernetes ,随后 传统 虚拟 化 巨头 


VMware 宣布 与 Docker3 虽 强 合 作 。2014 年 9 月 中 旬 ，Docker 更 是 获 
得 4000 万 美元 的 C 轮 融资 ， 以 推动 分 布 式 应 用 的 发 展 。 


目前 ，Docker 的 前 景 被 普遍 看 好 。 未 来 的 云 计 算 领 域 乃 至 整个 IT 
领域 ，Docker 都 必 将 扮演 不 可 或 缺 的 角色 。 为 了 帮助 大 家 更 好 地 认识 
Docker、 理 解 Docker 并 掌握 Docker , 本 书 从 Docker 源 码 的 角度 出 
发 ， 详 细 介 绍 Docker 的 染 构 、Docker 的 运行 以 及 Docker 的 特性 。 本 


章 主 要 介绍 Docker 架 构 。 


本 书 关 于 Docker 的 分 析 均 基于 Docker 1.2.0 版 本 的 源码 。 


本 章 目 的 是 在 理解 Docker 源 码 的 基础 上 分 析 Docker 架 构 ，, 分析 
过 程 主要 按照 以 下 三 个 部 分 进行 : 


-Docker 的 总 架构 图 。 
-Docker 架构 内 部 各 模块 功能 与 实现 的 分 析 。 


:通过 具体 的 Docker 命 令 ， 阐述 Docker 的 运行 流程 。 


1.2 Docker 总 架构 图 


作为 Linux 平 台 上 的 一 种 容 右 的 管理 引擎 ，Docker 并 不 像 其 他 大 
型 分 布 式 系统 那样 复杂 。Docker 的 源码 总 量 并 不 多 ， 而 且 清 晰 的 源码 
结构 使 得 Docker 的 学 习 成 本 并 不 高 。 换 言 之 ，Docker 源 码 的 学 习 过 
程 并 不 枯燥 ,我 们 可 以 从 中 学 到 很 多 东西 ， 如 Go 语言 的 运用 、 
Docker 架 构 的 设计 原理 等 。Docker 对 用 户 而 言 是 一 个 简单 的 C/S 架 
构 ,用户 通过 客户 端 与 服务 器 端 建立 通信 ,而 Docker 的 后 端 是 一 个 松 
耦合 的 架构 ， 架 构 中 的 模块 各 司 其 职 、 有 机 组 合 ， 支 撑 着 Docker 运 


一 


位 。 


Docker 的 总 架构 如 图 1-1 所 示 。 架 构 中 主要 的 模块 有 : 
DockerClient、 DockerDaemon、Docker Registry、Graph、 


Driver、libcontainer 以 及 Docker Container。 


对 用 户 而 言 ,Docker Client 是 与 Docker Daemon 建 立 通信 的 
最 佳 途径 。 用 户 通过 Docker Client 发 起 容器 的 管理 请 求 ， 请 求 最 终 


发 往 Docker Daemon。 


Docker Daemon 作 为 Docker 架 构 中 的 主体 部 分 ， 首先 具备 服 
务 端的 功能 ， 有 能 力 接收 Docker Client 发 起 的 请 求 ; 其 次 具备 


Docker Client 请 求 的 处 理 能 力 。Docker Daemon 内 部 所 有 的 任务 
均 由 Engine 来 完成 ， 且 每 一 项 工作 都 以 一 个 Job 的 形式 存在 。 


Docker Daemon 需 要 完成 的 任务 很 多 ， 因 此 job 的 种 类 也 很 
多 。 若 用 户 需要 下 载 容 痪 镜像 ，Docker Daemon 则 会 创建 一 个 名 
为 “pull" 的 job , 运行 时 从 Docker Registry 中 下 载 镜像 ， 并 通过 镜像 
管理 驱动 graphdriver 将 下 载 的 镜像 存储 在 graph 中 ; 若 用 户 需要 为 
Docker 容 器 创建 网 络 环境 ，Docker Daemon 则 会 创建 一 个 
名 “allocate_interface” 的 Job ,通过 网 络 驱 动 networkdriver 分 配 网 
络 接口 的 资源 .…… 


libcontainer 是 一 套 独 立 的 容 希 管理 解决 方案 ,这 套 解 决 方案 涉 
及 了 大 量 Linux 内 核 方 面 的 特性 ， 如 : namespaces、cgroups 以 及 
capabilities 等 。libcontainer 很 好 地 抽象 了 Linux 的 内 核 特性 ， 并 提 
供 完 整 、 明 确 的 接口 给 Docker Daemon。 


当 用 户 执 行 运行 容 兹 这 个 命令 之 后 ， 一 个 Docker 容 兹 就 处 于 运行 
状态 ， 该 容 问 拥有 隔离 的 运行 环境 、 独 立 的 网 络 栈 资源 以 及 受 限 的 资 
源 等 。 


Docker Client 
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1.3 Docker 各 模块 功能 与 实现 分 析 


下 面 我 们 将 从 Docker 的 总 染 构 图 入 手 ， 抽 离 出 染 构 内 的 各 个 模 
块 ， 并 对 各 个 模块 进行 更 为 细 化 的 染 构 分 析 与 功能 曾 述 。 


1.3.1 Docker Client 


Docker Client 是 Docker 架 构 中 用 户 与 Docker Daemon 建 立 通 
信和 的 客户 端 。 在 一 台 安装 有 Docker 的 机 器 上 上， 用户 可 以 使 用 可 执行 文 
件 docker 作 为 Docker Client , 发 起 众多 Docker 容 器 的 管理 请 求 。 


Docker Client 可 以 通过 以 下 三 种 方式 和 Docker Daemon 建 立 
通信 ， 分 别 为 : tcp : //host : port、unix : /path_to_socket 和 
fd : /socketfd。 为 简单 起 见 ， 本 书 主 要 使 用 第 一 种 方式 作为 讲述 两 
者 通信 的 原型 。 通 信 方 式 确定 后 ,DockercClient 与 Docker Daemon 
建立 连接 并 传输 请 求 时 ， 可 以 通过 命令 行 flag 参 数 的 形式 ， 设置 安 全 
传输 层 协议 ( TLS) 的 有 关 参 数 ， 保 证 传输 的 安全 性 。 


Docker Client 发 送 容 问 管 理 请 求 后 ,请 求 由 Docker Daemon 
接收 并 处 理 ， 当 Docker Client 接 收 到 返回 的 请 求 响应 并 做 简单 处 理 
后 , Docker Client 一 次 完整 的 生命 周期 就 此 结束 。 若 需要 继续 发 送 
容器 管理 请 求 ， 用 户 必须 再 次 通过 可 执行 文件 docker 创 建 Docker 
Client， 并 走 完 以 上 相同 的 流程 。 


1.3.2 Docker Daemon 


Docker Daemon 是 Docker 架 构 中 一 个 常 驻 在 后 台 的 系统 进 
程 。 所 请 的 “运行 Docker”，, 即 代 表 运 行 Docker Daemon。 总 之 ， 


DockerDaemon 的 作用 主要 有 以 下 两 方面 : 
:接收 并 处 理 Docker Client 发 送 的 请 求 。 
:管理 所 有 的 Docker 容 器 。 


Docker Daemon 运 行 时 ， 会 在 后 台 启 动 一 个 Server , Server 
负责 接收 Docker Client 发 送 的 请 求 ; 接收 请 求 后 ,Server 通 过 路 由 
与 分 发 调度 ， 找到 相应 的 Handler 来 处 理 请 求 。 


局 动 Docker Daemon 所 使 用 的 可 执行 文件 同样 是 docker ,与 
Docker Client 启 动 所 使 用 的 可 执行 文件 docker 相 同 。 既 然 Docker 
Client 与 Docker Daemon 都 可 以 通过 docker 二 进 制 文件 创建 ， 那么 
如 何 辨 别 两 者 就 变 得 非常 重要 。 实 际 上 ， 执行 docker 命 令 时 ， 通 过 传 
入 的 参数 可 以 辨别 Docker Daemon 与 Docker Client , 如 docker-d 
代表 Docker Daemon 的 启动 ，dockerps 则 代表 创建 Docker 
Client， 并 发 送 ps 请 求 。 


Docker Daemon 的 架构 大 致 可 以 分 为 三 部 分 : Docker 
Server、Engine 和 job。Daemon 的 架构 如 图 1-2 所 示 。 


1.Docker Server 


Docker Server 在 Docker 架 构 中 专门 服务 于 Docker Client ， 
的 功能 是 接收 并 调度 分 发 Docker Client 发 送 的 请 求 。Docker 
Server 的 架构 如 图 1-3 所 示 。 
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图 1-2 Docker Daemon 架 构 示 意图 
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1-3 Docker Server 架 构 示 意图 


在 Docker Daemon 的 启动 过 程 中 ，DockerServer 第 一 个 完 
成 。Docker Server 通 过 包 gorilla/mux , 创建 了 一 个 mux,Router 
路 由 益 ， 提 供 请 求 的 路 由 功能 。 在 Go 语言 中 , gorilla/mux 是 一 个 强 
大 的 URL 路 由 颖 以 及 调度 分 发 右 。 创 建 路 由 器 之 后 ,Docker Server 
为 mux.Router 中 添加 有 效 的 路 由 项 ,每 一 个 路 由 项 由 HTTP 请 求 方法 
( PUT、POST、GET 或 DELETE) 、URL 和 Handler 三 部 分 组 成 。 


由 于 Docker Client 通 过 HTTP 协 议 访问 Docker Daemon , 故 
DockerServer 创 建 完 mux.Router 之 后 ,将 Server 的 监听 地 址 以 及 


mux.Router 作 为 参数 ,创建 一 个 httpSrv= http.Server{} , 最终 执 
行 httpSrv.Serve( ) 开始 服务 于 外 部 请 求 。 


在 服务 过 程 中 ， Docker Server 在 listener 上 接收 Docker 
Client 的 访问 请 求 。 对 于 每 一 个 Docker Client 请 求 ，DockerServer 
均 会 创建 一 个 全 新 的 goroutine 来 服务 。 在 goroutine 中 ，Docker 
Server 首 先 读 取 请 求 内 容 ， 然 后 做 请 求解 析 工 作 ， 接 着 匹配 相应 的 路 
由 项 ， 随 后 调用 相应 的 Handler 来 处 理 ， 最 后 Handler 处 理 完 请 求 之 
后 给 Docker Client 回 复 响 应 。 


需要 注意 的 是 : Docker Server 在 Docker 的 局 动 过 程 中 运行 ， 
通过 一 个 名 为 “serveapi” 的 Job 来 实现 。 理 论 上 ,Docker Server 的 
运行 只 是 众多 Job 中 的 一 个 ， 但 是 为 了 强调 Docker Server 的 重要 性 
以 及 它 为 后 续 ]ob 服 务 的 重要 特性 ， 本 书 将 “serveapi" 的 Job 单 独 抽 离 
出 来 分 析 ， 理 解 为 Docker Server。 


2.Engine 


Engine 是 Docker 架 构 中 的 运行 引擎 ， 同 时 也 是 Docker 和 运行 的 核 
心 模块 。Engine 存 储 着 大 量 的 容 闫 信息 ， 同 时 管理 着 Docker 大 部 分 
job 的 执行 。 换 言 之 ，Docker 中 大 部 分 任务 的 执行 都 需要 Engine 协 
助 ， 并 通过 Engine 匹 配 相 应 的 job 完成 job 的 执行 。 


在 Docker 源 码 中 ,有关 Engine 的 数据 结构 定义 中 含有 一 个 名 为 
handlers 的 对 象 。 该 handlers 对 象 存储 的 是 关于 众多 特定 Job 各 自 的 
处 理 方 式 handler。 举 例 说 明 ,Engine 的 handlers 对 象 中 有 一 项 
为 : {"create" : daemon.ContainerCreate , }， 则 说 明 当 执行 名 
为 “create” 的 J]ob 时 ,执行 的 是 daemon.ContainerCreate 这 个 


handler, 


除了 容 闫 管理 之 外 , Engine 还 接管 Docker Daemon 的 某 些 特定 
任务 。 当 Docker Daemon 遭 遇 到 自身 进程 需要 退出 的 情况 时 ， 
Engine 还 负责 完成 DockerDaemon 退 出 前 的 所 有 善后 工作 。 


3.Job 


Job 可 以 认为 是 Docker 架 构 中 Engine 内 部 最 基本 的 工作 执行 单 
元 。DockerDaemon 可 以 完成 的 每 一 项 工作 都 会 呈现 为 一 个 ob。 例 
如 ,在 Docker 容 闫 内 部 运行 一 个 进程 ， 这 是 一 个 job ; 创建 一 个 新 的 
容 希 ， 这 是 一 个 job ; 在 网 络 上 下 载 一 个 文档 ,这 是 一 个 job ; 包括 之 
前 在 Docker Server 部 分 谈 及 的 ， 创 建 Server 服 务 于 HTTP 协 议 的 
API , 这 也 是 一 个 Job， 等 等 。 


有 关 job 接 口 的 设计 ,与 UNIX 进 程 非常 相仿 。 比 如 说 ,Job 有 一 
个 名 称 ， 有 运行 时 参数 ， 有 环境 变量 ， 有 标准 输入 与 标准 输出 ， 有 标 
准 错误 ， 还 有 返回 状态 等 。 


对 于 job 而 言 ,定义 完毕 之 后 ， 运行 才能 完成 job 自身 真正 的 使 
命 。jJob 的 运行 另 数 Run( ) 则 用 以 执行 job 本 身 。 


1.3.3 Docker Reglstry 


Docker Registry 是 一 个 存储 容器 镜像 ( Docker Image) 的 仓 
库 。 容 问 镜 像 ( Docker Image) 是 容 背 创建 时 用 来 初始 化 容 怖 
rootfs 的 文件 系统 内 容 。Docker Registry 将 大 量 的 容 怖 镜像 汇集 在 
一 起 ， 并 为 分 散 的 Docker Daemon 提 供 镜 像 服务 。 


Docker 的 运行 过 程 中 ， 有 三 种 情况 可 能 与 Docker Registry 通 
信 ,分别 为 搜索 镜像 、 下 载 镜像 、 上 传 镜 像 。 这 三 种 情况 所 对 应 的 
Job 名 称 分 别 为 Search、pull 和 push。 


不 同 场景 下 ,Docker Daemon 可 以 使 用 不 同 的 Docker 
Registry。 公 有 Registry 与 私有 Regsitry 就 是 两 种 场景 模式 不 同 的 
Docker Registry。 其 中 ， 大 家 熟知 的 Docker Hub ,就 是 全 球 范 围 
内 最 大 的 公有 Registry。Docker 可 以 通过 互联 网 访问 Docker Hub ， 
并 下 载 容 比 镜像 ; 同时 Docker 也 人 允许 用 户 构建 本 地 私有 Registry ， 
使 容 莫 镜像 的 获取 在 内 网 完成 。 


1.3.4 Graph 


Graph 在 Docker 架 构 中 扮演 的 角色 是 容器 镜像 的 保管 者 。 不 论 
是 Docker 下 载 的 镜像 ， 还 是 Docker 构 建 的 镜像 ， 均 由 Graph 统一 化 
管理 。 由 于 Docker 支 持 多 种 不 同 的 镜像 存储 方式 ， 如 aufs、 
devicemapper、Btrfs 等 ， oo 
而 存在 一 些 差异 。 对 Docker 而 言 ， 同 一 种 类 型 的 镜像 被 称 为 一 
repository， 如 名 称 为 ubuntu 的 镜像 都 同属 一 个 repository ; 而 同 
一 个 repository 下 的 镜像 则 会 因 tag 存 在 差异 而 不 同 ， 如 ubuntu 这 个 
repository 下 有 tag 为 12.04 的 镜像 ， 也 有 tag 为 14.04 的 镜像 。 
Docker 中 Graph 的 架构 如 图 1-4 所 示 。 
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图 1-4 Graph 架构 示意 图 


本 书 对 Graph 以 及 容 冀 镜像 ( Docker Image) 的 分 析 将 以 aufs 
为 主 ， 并 在 第 8 章 进行 深入 分 析 。 


1.3.5 Driver 


Driver 是 Docker 架 构 中 的 驱动 模块 。 通 过 Driver 驱 动 ，Docker 
可 以 实现 对 Docker 容 右 运 行 环境 的 定制 ， 定制 的 维度 主要 有 网 络 环 
境 、 存 储 方式 以 及 容器 执行 方式 。 需 要 注意 的 是 ，Docker 运 行 的 生命 
周期 中 ， 并 非 用 户 所 有 的 操作 都 是 针对 Docker 容 器 的 管理 ， 同时 包括 
用 户 对 Docker 运 行 信息 的 获取 ， 还 包括 Docker 对 Graph 的 存储 与 记 
录 等 。 因 此 ， 为 了 将 仅 与 Docker 容 器 有 关 的 管理 从 Docker 
Daemon 的 所 有 远 辑 中 区 分 开 来 ，Docker 的 创造 者 设计 了 Driver 层 
来 抽象 不 同类 别 各 自 的 功能 范畴 。 


Docker Driver 的 实现 可 以 分 为 以 下 三 类 驱动 : graphdriver、 


networkdriver 和 execdriver。 


graphdriver 主 要 用 于 完成 容 希 镜像 的 管理 ， 包 括 从 远程 Docker 
Registry 上 下 载 镜 像 并 进行 存储 ,也 包括 本 地 构建 完 镜像 后 的 存储 。 
当 用 户 下 载 指 定 的 容 兹 镜像 时 ,，graphdriver 将 容 莫 镜像 分 层 存 储 在 
本 地 的 指定 目录 下 ; 同时 当 用 户 需 要 使 用 指定 的 容 右 镜像 来 创建 容器 
时 ,graphdriver 从 本 地 镜像 存储 目录 中 获取 指定 的 容器 镜像 ， 并 按 
特定 规则 为 容 右 准备 rootfs ; 另外 ， 当 用 户 需要 通过 指定 Dockerfile 
构建 全 新 镜像 时 ， graphdriver 会 负责 新 镜像 的 存储 管理 。 


在 graphdriver 的 初始 化 过 程 之 前 ， 有 4 种 文件 系统 或 类 文件 系统 
的 驱动 Driver 在 DockerDaemon 内 部 注册 ， 它 们 分 别 是 aufs、 
btrfs、vfs 和 devmapper。 其 中 ，aufs、btrfs 以 及 devmapper 用 
于 容 怖 镜像 的 管理 ，vfs 用 于 容 希 Volume 的 管理 。Docker 在 初始 化 
之 时 ,优先 通过 获取 系统 环境 变量 “DOCKER_DRIVER" 来 提取 所 使 用 
driver 的 指定 类 型 。 因 此 ， 之 后 所 有 的 Graph 操作 ， 都 使 用 该 driver 
来 执行 。Docker 镜 像 是 Docker 技 术 中 非常 天 键 的 。2014 年 12 月 ， 
在 Linux 3.18-rc2 版 本 中 OverlayFS 被 合并 至 Linux 内 核 主线 ,在 
Docker 1.4.0 版 本 发 布 时 , Docker 官 方 宜 布 支持 overlay 这 一 类 
graphdriver , 即 用 户 在 局 动 Docker Daemon 时 可 以 选择 制定 
graphdriver 的 类 型 为 overlay。graphdriver 的 架构 如 图 1-5 所 示 。 
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图 1-5 graphdriver 架 构 示 意图 


networkdriver 的 作用 是 完成 Docker 容 器 网 络 环境 的 配置 ,其 中 
包括 Docker Daemon 启 动 时 为 Docker 环 境 创建 网 桥 ; Docker 容 厂 
创建 前 为 其 分 配 相应 的 网 络 接口 资源 ; 以 及 为 Docker 容 怖 分 配 IP、 站 
口 并 与 簿 主机 做 NAT 剖 口 映射 ， 设 置 容 闫 防火 墙 策略 等 。 
networkdriver 的 架构 如 图 1-6 所 示 。 
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图 1-6 networkdriver 架 构 示 意图 


execdriver 作 为 Docker 容 器 的 执行 驱动 ， 负责 创建 容器 运行 时 
的 命名 空间 ,负责 容器 资源 使 用 的 统计 与 限制 ,负责 容器 内 部 进程 的 


真正 运行 等 。 在 Docker 0.9.0 版 本 之 前 ，execdriver 只 能 通过 LXC 驴 
动 来 实现 容 希 的 局 动 管理 。 实 际 上 ,当时 Docker 通 过 LXC 驱 动 调用 
Linux 下 的 LXC 工 具 管 理 容 怖 的 创建 ， 并 控制 管理 容 闫 的 生命 周期 。 

从 Docker 0.9.0 开 始 ， 在 继续 支持 LXC 的 情况 下 ,Docker 的 
execdriver 默 认 使 用 native 驱 动 ，native 驱 动 完全 独立 于 LXC ,属于 
Docker 项 目下 第 一 个 全 新 的 子 项 目 ， 用 于 容 癌 的 创建 与 管理 。 
Docker 上 默认 使 用 native 驱 动 的 具体 体现 为 : Docker Daemon 启 动 
过 程 中 加 载 的 ExecDriverflag 参 数 在 配置 文件 中 已 经 被 设 为 native。 
native 这 个 execdriver 的 存在 ， 使 得 Docker 对 Linux 容 器 的 创建 与 
管理 有 了 自己 的 解决 方案 。execdriver 架 构 如 图 1-7 所 示 。 
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1-7 execdriver 架 构 示 总 多 


1.3.6 libcontainer 


libcontainer 是 Docker 架 构 中 一 个 使 用 Go 语言 设计 实现 的 库 ， 
设计 初衷 是 希望 该 库 可 以 不 依靠 任何 依赖 ， 直 接 访 问 内 核 中 与 容器 相 
关 的 系统 调用 。 


正 是 由 于 libcontainer 的 存在 ，Dockereo 以 直接 调用 
libcontainer , 而 最 终 操 作 容 器 的 namespaces、cgroups、 


apparmor、 网 络 设备 以 及 防火 墙 规则 等 。 这 一 系列 操作 的 完成 都 不 
需要 依赖 LXC 或 者 其 他 包 。libcontainer 架 构 如 图 1-8 所 示 。 
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图 1-8 ”libcontainer 示 意图 


男 外 ,libcontainer 提 供 了 一 整套 标准 的 接口 来 满足 上 层 对 容 兹 
管理 的 需求 。 或 者 说 ,libcontainer 屏 蔽 了 Docker 上 层 对 容器 的 直接 
管理 。 又 由 于 libcontainer 使 用 Go 这 种 跨 平台 的 语言 开发 实现 ， 且 本 
身 又 可 以 被 上 层 多 种 不 同 的 编程 语言 访问 ， 因此， 很 难说 未 来 的 
Docker 一 定 会 与 Linux 平 台 紧 紧 捆 绑 在 一 起 。Docker Daemon 的 逻 
辑 完全 有 可 能 位 于 其 他 非 Linux 操 作 系统 的 平台 上 ， 仅 仅 通 过 
libcontainer 的 远程 调用 来 实现 对 Docker 容 器 的 管理 。 另 一 方面 ， 
libcontainer 与 Docker Daemon 的 松 耦 合 设计 ， 似 乎 让 用 户 感受 到 
了 除 Linux Container 之 外 其 他 的 容器 技术 接 入 Docker Daemon 的 
可 能 性 。libcontainer 承 接 Linux 内 核 与 Docker Daemon 的 同时 ， 
也 让 Docker 的 生态 在 跨 平 台 方面 充满 生机 。 与 此 同时 ，Microsoft 在 
其 著名 云 计 算 平 台 Azure 中 ， 也 添加 了 对 Docker 的 支持 ， 可 见 
Docker 的 开放 程度 与 业界 的 火热 度 。 


暂 不 谈 Docker , 由 于 本 身 完 善 的 功能 以 及 与 应 用 系统 的 松 耦 合 特 
性 ,libcontainer 很 有 可 能 会 在 众多 其 他 以 容器 为 原型 的 平台 出 现 ， 
同时 也 很 有 可 能 众生 出 云 计 算 领域 全 新 的 项 目 。 


1.3.7/ Docker Container 


Docker Container( Docker 容 器 ) 是 Docker 架 构 中 服务 交付 的 
最 终 体 现形 式 。Docker 通 过 DockerDaemon 的 管理 ， libcontainer 
的 执行 ， 最 终 创建 Docker 容 器 。Docker 容 器 作为 一 个 交付 单位 ， 功 
能 类 似 于 传统 意义 上 的 虚拟 机 ( _ Virtual Machine) ， 具 备 资源 受 限 、 
环境 与 外 界 隔离 的 特点 。 然 而 ， 实 现 手段 却 与 KVM、Xen 等 传统 虚拟 
化 技术 大 相 径 庭 。 


Docker 容 希 的 从 无 到 有 ， 涉 及 Docker 利 用 到 的 很 多 技术 。 总 而 
言 之 , 用户 可 以 根据 自己 的 需求 , 通过 Docker Client 向 Docker 
Daemon 发 送 容 器 的 创建 与 启动 请 求 ， 请 求 中 将 携带 容器 的 配置 信 
息 ， 从 而 达到 定制 相应 Docker 容 器 的 目 的 。 用 户 对 Docker 容 器 的 配 
置 有 以 下 4 个 基本 方面 : 


通过 指定 容 需 镜像 ， 使 得 Docker 容 器 可 以 自 定 义 rootfs 等 文件 系 


:通过 指定 物理 资源 的 配额 ,如 CPU、 内 存 等 ， 使 得 Docker 容 怖 使 
用 受 限 的 物理 资源 。 


` 通 过 配 苞 容 右 网 络 及 其 安全 策略 ， 使 得 Docker 容 问 拥 有 独立 且 安 
全 的 网 络 环境 。 


"通过 指定 容 旨 的 运行 命令 ， 使 得 Docker 容 兹 执行 指定 的 任务 。 


Docker 容 器 示意 图 如 图 1-9 所 示 。 
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图 1-9 Docker 容器 示意 图 


1.4 Docker 运 行 案例 分 析 


1.3 节 着 重 介绍 了 Docker 架 构 中 各 个 模块 的 功能 ， 学 完 后 我 们 可 
以 对 Docker 的 架构 有 一 个 宏观 的 认识 。 熟 悉 一 款 软件 ， 研 究 一 个 系 
统 ， 从 静态 的 角度 认识 架构 的 各 个 模块 ， 仪 仪 是 第 一 步 ; 从 动态 的 角 
度 ,掌握 软件 或 者 系统 的 运行 原理 ， 即 熟知 架构 中 模块 间 的 通信 远 
辑 , 无 疑 会 让 自己 对 软件 或 系统 的 理解 更 上 一 层 楼 。 本 节 将 从 实际 的 
Docker 运 行 案例 出 发 ,串联 Docker 各 模块 ， 从 而 学 习 Docker 的 运行 
流程 。 分 析 原 型 为 Docker 中 的 docker pull 与 docker run 两 个 命令 。 


1.4.1 docker pull 


1.3 节 中 我 们 提 到 ， 用 户 可 以 为 容 闫 指定 镜像 ， 作 为 容 闫 运行 时 
的 rootfs ,既然 如 此 ， 镜像 从 何 而 来 则 成 为 一 个 关键 。 答 案 很 简单 ， 
一 切 都 归功 于 docker pull 命 令 。 


docker pull 命 令 的 作用 是 : Docker Daemon 从 Docker 
Registry 下 载 指定 的 容 希 镜像 ， 并 将 镜像 存储 在 本 地 的 Graph 中 ， 以 
备 后 续 创建 Docker 容 莫 时 使 用 。docker pull 命 令 的 执行 流程 如 图 1- 
10 所 示 。 


图 1-10 中 有 编号 的 秆 头 表 示 docker pull 命 令 在 发 起 后 ，Docker 
架构 中 相应 模块 所 做 的 一 系列 运行 操作 。 下 面 我 们 逐一 分 析 这 些 步 


又 。 


UH 


1) Docker Client 处 理 用 户 发 起 的 docker pull 命 令 ， 解析 完 请 
求 以 及 参数 之 后 ， 发送 一 个 HTTP 请 求 给 Docker Server , HTTP 请 求 
方法 为 POST ，, 请 求 URL 为 "/images/create ? "十 "XXX" ,实际 意义 
为 下 载 相应 的 镜像 。 


2) Docker Server 接 收 以 上 HTTP 请 求 ， 并 交 给 mux.Router ， 
mux.Router 通 过 URL 以 及 请 求 方法 类 型 来 确定 执行 该 请 求 的 具体 


handler。 


3) mux.Router 将 请 求 路 由 分 发 至 相应 的 handler , 具体 为 


PostlimagesCreate。 


4) 在 PostlImageCreate 这 个 handler 之 中 ， 创 建 并 初始 化 一 个 
名 为 "pull" 的 Job ,之 后 触发 执行 该 job。 


5) 名 为 "pull" 的 Job 在 执行 过 程 中 执行 pullRepository 操 作 ， 即 
从 Docker Registry 中 下 载 相应 的 一 个 或 者 多 个 Docker 镜 像 。 


) 名 为 "pull" 的 Job 将 下 载 的 Docker 镜 像 交 给 graphdriver 管 
理 。 


7) graphdriver 负 责 存储 Docker 镜 像 ， 一 方面 将 实际 镜像 存储 
至 本 地 文件 系统 中 ， 另 一 方面 为 镜像 创建 对 象 , 由 Docker Daemon 
统一 理惠 : 
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图 1-10 ”docker pull 命 令 执行 流程 示意 图 


1.4.2 docker run 


docker run 命 令 的 作用 是 创建 一 个 全 新 的 Docker 容 右 ， 并 在 容 
器 内 部 运行 指定 命令 。Docker Daemon 处 理 用 户 发 起 的 这 条 命令 
时 ， 所 做 工作 可 以 分 为 两 部 分 : 第 一 ， 创 建 Docker 容 屡 对 象 ， 并 为 容 
厂 准 备 所 需 的 rootfs ; 第 二 ， 创建 容 右 的 运行 环境 ， 如 网络 环境 、 资 
源 限制 等 ， 最 终 真正 运行 用 户 指令 。 因 此 ， 在 dockerrun 命 令 的 完整 
执行 流程 中 ,Docker Client 给 Docker Server 发 送 了 两 次 HTTP 请 
求 ， 第 二 次 请 求 的 发 起 取决 于 第 一 次 请 求 的 返回 状态 。docker run 命 
令 执行 流程 如 图 1-11 所 示 。 
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图 1-11 docker run 命 令 执行 流程 示意 区 


图 1-11 中 有 编号 的 箭头 表示 dockerrun 命 令 在 发 起 后 ，Docker 
架构 中 相应 模块 所 做 的 一 系列 运行 。 下 面 我 们 逐一 分 析 这 些 步骤 : 


1) Docker Client 处 理 用 户 发 起 的 docker run 命 令 ， 解 析 完 请 
求 与 参数 之 后 ,向 Docker Server 发 送 一 个 HTTP 请 求 ，HTTP 请 求 方 
法 为 POST ,请求 URL 为 "/containers/create ? "二 "XXX" ,实际 意义 
为 创建 一 个 容器 对 象 ， 即 Docker Daemon 程 序 逻 辑 中 的 容器 对 象 ， 
并 非 实际 运行 的 容 笑 。 

2) Docker Server 接 收 以 上 HTTP 请 求 ， 并 交 给 mux.Router ， 
mux.Router 通 过 URL 以 及 请 求 方法 来 确定 执行 该 请 求 的 具体 


handler, 


3) mux.Router 将 请 求 路 由 分 发 至 相应 的 handler ,具体 为 


PostContainersCreate 。 


4) 在 PostContainersCreate 这 个 handler 之 中 ， 创 建 并 初始 化 
一 个 名 为 "create" 的 Job， 之 后 触发 执行 该 job。 


5) 名 为 "create" 的 Job 在 运行 过 程 中 执行 Container.Create 操 
作 ,该 操作 需要 获取 容器 镜像 来 为 Docker 容 器 准备 rootfs， 通 过 
graphdriver 完 成 。 


6) graphdriver 从 Graph 中 获取 创建 Docker 容 器 rootfs 所 需要 
的 所 有 镜像 。 


7) graphdriver 将 rootfs 的 所 有 镜像 通过 某 种 联合 文件 系统 的 方 
式 加 载 至 Docker 容 器 指定 的 文件 目录 下 。 


) 大 以 上 操作 全 部 正常 执行 ， 没 有 运 回 错误 或 异常 ， 则 Docker 
Client 收 到 Docker Server 返 回 状态 之 后 ,发 起 第 二 次 HTTP 请 求 。 
请 求 方法 为 "POST"， 请求 URL 
为 "/containers/"+container_ID+"/start" , 实际 意义 为 局 动 时 才 创 
建 完毕 的 容器 对 象 ， 实 现 物理 容器 的 真正 运行 。 


9) Docker Server 接 收 以 上 HTTP 请 求 ， 并 交 给 mux.Router ， 
mux.Router 通 过 URL 以 及 请 求 方法 来 确定 执行 该 请 求 的 具体 


handler, 


10) mux.Router 将 请 求 路 由 分 发 至 相应 的 handler ,具体 为 


PostContainersStart, 


) 在 PostContainersStart 这 个 handler 之 中 ,创建 并 初始 化 
名 为 "start" 的 Job ,之 后 角 发 执行 该 Job。 


12) 名 为 "start" 的 Job 执 行 需 要 完成 一 系列 与 Docker 容 器 相关 
的 配置 工作 ， 其 中 之 一 是 为 Docker 容 器 网 络 环境 分 配 网 络 资源 ,如 IP 
资源 等 ， 通 过 调用 networkdriver 完 成 。 


13) networkdriver 为 指定 的 Docker 容 器 分 配 网 络 资 源 ， 其 中 
有 IP、port 等 ， 另 外 为 容 蓝 设置 防火 墙 规则 。 


14) 返回 名 为 "start" 的 Job ,执行 完 一 些 辅助 性 操作 后 ,Job 开 
始 执行 用 户 指令 ， 调 用 execdriver。 


15) execdriver 被 调用 ， 开 始 初始 化 Docker 容 闫 内 部 的 运行 环 
境 ， 如 命名 空间 、 资 源 控 制 与 隔离 ， 以 及 用 户 命令 的 执行 ， 相 应 的 操 
作 转 交 至 libcontainer 来 完成 。 


16) libcontainer 被 调用 ， 完 成 Docker 容 器 内 部 的 运行 环境 初 
始 化 ， 并 最 终 执行 用 户 要 求 启动 的 命令 。 


15 总 此 


本 章 从 Docker 1.2.0 的 源码 入 手 ， 首先 分 析 抽 象 出 Docker 的 架 
构图 ,并 对 该 架构 图 中 的 各 个 模块 进行 功能 与 实现 的 简要 分 析 ， 最 后 
通过 Docker 的 两 个 基础 命令 展示 了 Docker 内 部 的 运行 。 


通过 对 Docker 染 构 的 学 习 ， 可 以 全 面 深化 对 Docker 设 计 、 功 能 
与 价值 的 理解 。 同 时 在 借助 Docker 实 现 用 户 定制 的 分 布 式 系 统 时 ,也 
能 更 好 地 找到 已 有 平台 与 Docker 较 为 理想 的 契合 点 。 另 外 ,熟悉 
Docker 现 有 以 构 以 及 设计 思想 ， 也 能 为 云 计算 PaaS 领 域 带 来 更 多 的 
局 示 ， 催 生出 更 多 创新 想法 。 


第 2 章 ”Docker Client 创 建 与 命令 执行 
2.1 引言 


如 今 ， 作 为 业界 领先 的 轻 量 级 虚拟 化 容 右 管理 引擎 ，Docker 给 全 
球 开发 者 提供 了 一 种 新 颖 、 便 捷 的 软件 集成 测试 与 部 闭 之 道 。 团 队 开 
发 软件 时 ，Docker 可 以 提供 可 复 用 的 运行 环境 、 灵 活 的 资源 配置 、 便 
捷 的 集成 测试 方法 ， 以 及 一 键 式 的 部 著 方 式 。 可 以 说 ，Docker 在 简化 
持续 集成 、 运 维 部 署 方面 将 其 功能 发 挥 得 淋漓 尽 致 ， 它 让 开发 者 从 重 
复 的 持续 集成 、 运 维 部 著 中 完全 解放 出 来 ， 把 精力 真正 地 倾注 在 开发 
二 


然而 ,要 把 Docker 的 功能 发 挥 到 极致 ， 并 非 一 件 易 事 。 在 深刻 理 
解 Docker 架 构 的 情况 下 ， 熟练 掌握 Docker Client 的 使 用 也 非常 有 必 
要 。 前 者 可 以 参阅 第 1 章 ， 本 章 主 要 针对 后 者 ， 从 源码 的 角度 分 析 
Docker Client， 力 求 帮 助 开 发 者 更 深刻 地 理解 Docker Client 的 具体 
实现 ， 最 终 更 好 地 掌握 Docker Client 的 使 用 方法 。 


本 章 基 于 Docker 1.2.0 的 源码 ,分析 Docker Client 的 内 容 。 主 
要 包括 两 个 部 分 ， 分 别 是 DockerClient 的 创建 与 Docker Client 对 命 
令 的 执行 。 两 部 分 分 析 的 具体 内 容 如 下 。 


第 一 部 分 分 析 Docker Client 的 创建 。 这 部 分 的 分 析 可 分 为 以 下 


三 个 步骤 : 


分 析 如 何 通过 docker 命 令 ， 解 析出 命令 行 flag 参 数 ， 以 及 


docker 命 令 中 的 请 求 参 数 。 


分 析 如 何 处 理 具 体 的 flag 参 数 信息 ， 并 收集 Docker Client 所 需 
的 配置 信息 。 


.分 析 如 何 创 建 一 个 Docker Client。 


第 二 部 分 在 已 有 Docker Client 的 基础 上 ，, 分析 如 何 执行 docker 
命令 。 这 部 分 的 分 析 又 可 分 为 以 下 两 个 步 又 。 


分析 如 何 解析 docker 命 令 中 的 请 求 参 数 ， 获 取 相 应 请 求 的 类 


Ee: 


分 析 Docker Client 如 何 执行 具体 的 请 求 命 令 ， 最 终 将 请 求 发 送 


至 Docker Server。 


2.2 创建 Docker Client 


对 于 Docker 这 样 一 个 Client/Server 的 架构 ， 客户 端的 存在 意味 
着 Docker 相 应 任务 的 发 起 。 用 户 首先 需要 创建 一 个 DockerClient ， 
随后 将 特定 的 请 求 类 型 与 参数 传递 至 Docker Client , 最终 由 Docker 
Client 转 义 成 Docker Server 能 识别 的 形式 ， 并 发 送 至 Docker 


Server。 


Docker Client 的 创建 实质 上 是 Docker 用 户 通过 二 进 制 可 执行 文 
件 docker , 创建 与 Docker Server 建 立 联 系 的 客户 端 。 以 下 分 3 个 小 
节 分 别 阐述 Docker Client 的 创建 流程 。 


Docker Client 完 整 的 运行 流程 如 图 2-1 所 示 。 
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图 2-1 DockerClient 的 运行 流程 


通过 学 习 图 2-1， 我 们 可 以 更 为 清晰 地 了 解 Docker Client 创 建 及 
执行 请 求 的 过 程 。 其 中 涉及 诸多 Docker 源 码 层次 中 的 专 有 名 词 ， 本 章 


后 续 会 一 一 解释 与 分 析 。 


2.2.1 Docker 命 令 的 flag 参 数 解析 


众所周知 ,在 Docker 的 具体 实现 中 ,Docker Server 与 Docker 
Client 均 由 可 执行 文件 docker 来 完成 创建 并 局 动 。 那 么 ， 了 解 
docker 可 执行 文件 通过 何 种 方式 来 区 分 到 底 是 Docker Server 还 是 
Docker Client， 就 显得 尤为 重要 。 


首先 通过 docker 命 令 举 例 说 明 其 中 的 区 别 。Docker Server 的 局 
动 ,命令 为 docker-d 或 docker--daemon=true ; 而 Docker Client 
的 启动 则 体现 为 docker--daemon=false ps、docker pull NAME 
等 。 


其 实 ,对 于 Docker 请 求 中 的 参数 ， 我们 可 以 将 其 分 为 两 类 : 第 一 
类 为 命令 行 参数 ， 即 docker 程 序 运行 时 所 需 提 供 的 参数 ， 如 : -D、-- 
daemon= true、--daemon=false 等 ; 第 二 类 为 docker 发 送 给 


Docker Server 的 实际 请 求 参数 ， 如 : ps、pull NAME 等 。 

对 于 第 一 类 ， 我们 习惯 将 其 称 为 flag 参 数 ， 在 Go 语言 的 标准 库 
中 ,专门 为 该 类 参数 提供 了 一 个 flag 包 ，, 方便 进行 命令 行 参 数 的 解 
析 。 


清楚 docker 二 进 制 文件 的 使 用 以 及 基本 的 命令 行 fag 参 数 之 后 ， 
我 们 可 以 进入 实现 Docker Client 创 建 的 源码 中 ,位 
于 ./docker/docker/docker.go。 这 个 go 文件 包含 了 整个 Docker 的 
main 喘 数 ， 也 就 是 整个 Docker( 不 论 Docker Daemon 还 是 
Docker Client) 的 运行 入口 。 部 分 main 兄 数 代 码 如 下 : 


func main() { 
if reexec.Init() { 
return 


} 
flag.Parse() 
// FIXME: validate daemon flags here 


以 上 源码 实现 中 ,首先 判断 reexec.Init( ) 方法 的 返回 值 ， 若 为 
真 ， 则 直接 退出 运行 ， 否则 将 继续 执行 。reexec.Init( ) 函数 的 定义 
位 于 ./docker/reexec/reexec.g0 , 可 以 发 现 由 于 在 docker 运 行 之 前 
没有 任何 Initializer 注 册 , 故 该 代码 段 执行 的 返回 值 为 假 。reexec 存 
在 的 作用 是 : 协调 execdriver 与 容器 创建 时 dockerinit 这 两 者 的 关 
系 。 第 13 章 在 分 析 dockerinit 的 启动 时 ，, 将 详细 讲解 reexec 的 作 
用 。 


判断 reexec.Ilnit( ) 之 后 , Docker 的 main 函 数 通过 调用 
flag.Parse( ) 六 数 ,解析 命令 行 中 的 flag 参 数 。 如 果 熟 悉 Go 语 言 中 
的 flag 参 数 ， 一 定 知道 解析 flag 参 数 的 值 之 前 ， 程序 必须 先 定 义 相 应 
的 flag 参 数 。 进 一 步 查看 Docker 的 源码 ， 我 们 可 以 发 现 Docker 


在 ./dockerdockerflag.go 中 定义 了 多 个 flag 参 数 ， 并 通过 init 多 数 
了 部 分 fag 参 数 的 初始 化 。 代 码 如 下 : 


Var ( 
flVersion = flag.Bool([]string{"v", "-version"}, false, "Print version 
information and quit") 
flDaemon = flag.Bool([]string{"d", "-daemon"}, false, "Enable daemon mode") 
flDebug = flag.Bool([]string{"D", "-debug"}, false, "Enable debug mode") 
flSocketGroup = flag.String([]string{"G", "-group"}, "docker", "Group to 
assign the unix socket specified by -H when running in daemon modeuse '' (the 
empty string) to disable setting of a group") 
flEnableCors = flag.Bool([]string{"#api-enable-cors", "-api-enable- 
cors"}, false, "Enable CORS headers in the remote API") 
flTls = flag.Bool([]string{"-tls"}, false, "Use TLS; implied by tls- 
verify flags") 
flTlsVerify = flag.Bool([]string{"-tlsverify"}, false, "Use TLS and 
verify the remote (daemon: verify client, client: verify daemon)") 
// these are initialized in init() below since their default values 
depend on dockerCertPath which isn't fully initialized until init() runs 
flCa *string 
flCert *string 
fLKey *string 
flHosts []string 
) 


func init() { 

flCa = flag.String([]string{"-tlscacert"}, filepath.Join(dockerCertPath, 
defaultCaFile), "Trust only remotes providing a certificate signed by the CA 
given here") 

flCert = flag.String([]string{"-tlscert"}, filepath.Join(dockerCertPath, 
defaultCertFile), "Path to TLS certificate file") 

fLKey = flag.String([]string{"-tlskey"}, filepath.Join(dockerCertPath, 
defaultKeyFile), "Path to TLS key file") 

opts.HostListVar(&flHosts, []string{"H", "-host"}, "The socket(s) to 
bind to in daemon mode\nspecified using one or more tcp://host:port, 
unix:///path/to/socket, fd://* or fd://socketfd.") 
} 


以 上 源码 展示 了 Docker 如 何 定义 fag 参 数 ， 以 及 在 init 明 数 中 实 
现 部 分 flag 参 数 的 初始 化 。Docker 的 main 函 数 执行 前 ， 这 些 变量 创 
建 以 及 初始 化 工作 已 经 全 部 完成 。 这 里 涉及 了 Go 语言 的 一 个 特性 ， 即 
init 约 数 的 执行 。Go 语 言 中 引入 其 他 包 ( import package) 、 变 量 
的 定义 、init 纹 数 以 及 main 阵 数 这 四 者 的 执行 顺序 如 图 2-2 所 示 。 


关于 Golang 中 的 init 级 数 ， 深 入 分 析 可 以 得 出 以 下 特性 : 
init 约 数 用 于 程序 执行 前 包 的 初始 化 工作 ， 比 如 初始 化 变量 等 ; 
每 个 包 可 以 有 多 个 init 铝 数 ; 

' 包 的 每 一 个 源 文件 也 可 以 有 多 个 init 铝 数 ， 

:同一 个 包 内 的 init 纹 数 的 执行 顺序 没有 明确 的 定义 ; 

不同 包 的 init 级 数 按照 包 导 入 的 依赖 关系 决定 初始 化 的 顺序 ; 


init 多 数 不 能 被 调用 ,而 是 在 main 约 数 调用 前 自动 被 调用 。 


import pkgl 





图 2-2 ”Go 语言 程序 加 载 顺 序 图 


清楚 Go 语言 一 些 基本 的 特性 之 后 ， 回 到 Docker 中 来 。Docker 的 


main 阴 数 执行 之 前 ，Docke 中 经 定义 了 诸多 flag 参 数 ， 并 对 很 多 
flag 参 数 进行 初始 化 。 定 义 并 初始 化 的 命令 行 fag 参 数 有 : 
fVersion、fDaemon、flDebug、flSocketGroup、 
flEnableCors、 flTls、 flTlsVerify、flCa、flCert、flKkey、flHosts 


等 。 
以 下 具体 分 析 fIDaemon : 


定义 : liDaemon=flag.Bool( [lstring{"d" , "-daemon"}, 


false , "Enable daemon mode") ; 
:fIDaemon 的 类 型 为 Bool| 类 型 ; 


:Daemon 名 称 为 "d" 或 者 "-daemon" ，, 该 名 称 会 出 现在 docker 
命令 中 ， 如 docker-d : 


fIDaemon 的 默认 值 为 false ; 
:f1iDaemon 的 用 途 信息 为 "Enable daemon mode'" ， 
访问 fIDaemon 的 值 时 ,使 用 指针 *fIDaemon 解 引用 访问 。 


在 解析 命令 行 flag 参 数 时 ， 以 下 语句 为 合法 的 ( 以 fIDaemon 为 
例 ) 


'-d ,，--daemon 
-d=true,，--daemon=true 
-d= "true" , --daemon= "true" 
-d='true' , --daemon='true 


当 解 析 到 第 一 个 非 定 义 的 flag 参 数 时 ， 命 令 行 flag 参 数 解析 工作 
结束 。 举 例 说 明 , 当 执 行 docker 命 令 docker--daemon=false-- 
version= false ps 时 ,fag 参数 解析 主要 完成 两 个 工作 : 


:完成 命令 行 fag 参 数 的 解析 ,根据 flag 的 名 称 -daemon 和 - 
version ，, 得 知 具体 的 flag 参 数 为 HDaemon 和 flVersion ， 并 获得 相 
应 的 值 ， 均 为 false。 


` 遇 到 第 一 个 非 定义 的 flag 参 数 ps 时 ，flag 包 会 将 ps 及 其 之 后 所 有 
的 参数 存 入 flag.Args( ) ， 以 便 之 后 执行 Docker Client 具 体 的 请 求 
时 使 用 。 


如 需 深入 学 习 flag 的 实现 ， 可 以 参见 Docker 源 
码 ./dockervpkg/mflag/flag.go。 


2.2.2 处理 flag 信 息 并 收集 Docker Client 的 配 
四 信息 


理解 Go 语言 解析 fag 参 数 的 相关 知识 ， 可 以 很 大 程度 上 帮助 理解 
Docker 的 main 函 数 的 执行 流程 。 通 过 总 结 ， 首先 列 出 源码 中 处 理 的 
flag 信 息 以 及 收集 Docker Client 的 配置 信息 ,然后 再 一 一 进行 分 
析 : 


:处 理 的 flag 参 数 有 : flVersion、flDebug、flDaemon、 
flTlsVerify 以 及 flTls。 


:为 Docker Client 收 集 的 配置 信息 有 : protoAddrParts( 通过 
fiIHosts 参 数 获 得 ， 作 用 是 提供 Docker Client 与 Docker Server 的 通 
信 协 议 以 及 通信 地 址 ) 、tlsConfig( 通过 一 系列 flag 参 数 获得 ， 如 
*flTIs、*fiTlsVerify， 作 用 是 提供 安全 传输 层 协 议 的 保障 ) 。 


清楚 flag 参 数 以 及 Docker Client 的 配置 信息 之 后 ，, 我们 进入 
main 隙 数 的 源码 ， 具体 分 析 如 下 。 


在 flag.Parse( ) 之 后 的 源码 如 下 : 


if *flVersion { 
showVersion() 
return 


} 


以 上 代码 很 好 理解 ， 解 析 flag 参 数 后 ， 和 在 Docker 发 现 flag 参 数 
flVersion 为 真 ， 则 说 明 Docker 用 户 希 望 查看 Docker 的 版 本 信息 。 此 
时 ,Docker 调 用 showVersion( ) 显示 版 本 信息 ， 并 从 main 函 数 退 

否则 的 话 ， 继 续 往 下 执行 。 


if *flDebug { 
os.Setenv("DEBUG", "1") 
} 


铬 fliDebug 参 数 为 真 的 话 ，Docker 通 过 0s 包 中 的 Setenv 咒 数 创 
建 一 个 名 为 DEBUG 的 环境 变量 ， 并 将 其 值 设 为 "1" ; 继续 往 下 执行 。 


if len(flHosts) == 0 { 
defaultHost := os.Getenv("DOCKER HOST") 
if defaultHost == "" || *flDaemon { 


// If we do not have a host, default to unix socket 
defaultHost = fmt.Sprintf("unix://%s", api.DEFAULTUNIXSOCKET) 


if , err := api.ValidateHost(defaultHost); err != nil { 
log.Fatal (err) 


flHosts = append(flHosts, defaultHost) 


以 上 的 源码 主要 分 析 内 部 变量 flHosts。fHosts 的 作用 是 为 
Docker Client 提 供 所 要 连接 的 host 对 象 ， 也 就 是 为 Docker Server 
提供 所 要 监听 的 对 象 。 


在 分 析 过 程 中 ， 首 先 判 断 fHosts 变 量 是 否 长 度 为 0。 若 是 的 话 ， 
则 说 明 用 户 并 没有 显 性 传 入 地 址 ， 此 时 Docker 的 策略 为 选用 默认 值 。 
Docker 通 过 0s 包 获取 名 为 DOCKER_HOST 环 境 变量 的 值 ， 将 其 赋值 


于 defaultHost。 知 defaultHost 为 空 或 者 fIDaemon 为 真 ， 说 明 目 前 
还 没有 一 个 定义 的 host 对 象 ， 则 将 其 默认 设置 为 unix socket， 值 为 
api.DEFAULTUNIXSOCKET , 该 常量 位 

于 ./docker/api/common.go , 值 为 "/varrun/dockersock'" , 故 
defaultHost 为 "unix : ///var/run/docker.sock"。 验 证 该 
defaultHost 的 合法 性 之 后 ,将 defaultHost 的 值 追加 至 fliHost 的 末 
尾 ， 继 续 往 下 执行 。 当 然 若 flHost 的 长 度 不 为 0 , 则 说 明 用 户 已 经 指 
定 地 址 ， 同 样 继续 往 下 执行 。 


if *flDaemon { 
mainDaemon() 


return 


} 


若 fliDaemon 参 数 为 真 ， 则 说 明 用 户 的 需求 是 局 动 Docker 
Daemon。Docker 随 即 执行 mainDaemon 隙 数 ， 实 现 Docker 
Daemon 的 启动 ; 车 mainDaemon 国 数 执行 完毕 ， 则 退出 main 函 
数 。 一 般 mainDaemon 函 数 不 会 主动 终结 ,Docker Daemon 将 作 
为 一 个 常 驻 进程 运行 在 宿主 机 上 。 本 章 着 重 介绍 Docker Client 的 局 
动 , 故 假设 IDaemon 参 数 为 假 ， 不 执行 以 上 代码 块 。 继 续 往 下 执 


一 


位。 


if len(flHosts) > 1 1 
log.Fatal ("Please specify only one -H") 


} 
protoAddrParts := strings.SplitN(flHosts[0], "://", 2) 


由 于 不 执行 Docker Daemon 的 局 动 流程 ， 故 属于 Docker 
Client 的 执行 逻辑 。 首 先 ， 判断 fliHosts 的 长 度 是 否 大 于 1。 若 flHosts 
的 长 度 大 于 1， 则 说 明 需 要 新 创建 的 Docker Client 访 问 不 止 1 个 
Docker Daemon 地 址 ,显然 逻辑 上 行 不 通 ， 故 抛 出 错误 日 志 , 提醒 
用 户 只 能 指定 一 个 Docker Daemon 地 址 。 接 着 ,Docker 将 flHosts 
这 个 string 数 组 中 的 第 一 个 元 素 进行 分 害 |, 通过 " : //" 来 分 嘎 | , 分 害 | 出 
的 两 个 部 分 放 入 变量 protoAddrParts 数 组 中 。protoAddrParts 的 作 
用 是 : 解析 出 Docker Client 与 Docker Server 建 立 通信 的 协议 与 地 
址 ， 为 Docker Client 创 建 过 程 中 不 可 或 缺 的 配置 信息 之 一 。 一 般 情 
况 下 ,flHosts[0] 的 值 可 以 是 tcp : /0.0.0.0 : 237 5 或 者 


unix : ///var/run/docker.sock 等 。 


var ( 
cl *client.DockerCli 
tlsConfig tls.Config 


) 
tlsConfig.InsecureSkipVerify = true 


由 于 之 前 已 经 假设 过 iDaemon 为 假 ， 可 以 认定 main 函 数 的 运行 
是 为 了 Docker Client 的 创建 与 执行 。Docker 在 这 里 创建 了 两 个 变 
量 : 一 个 为 类 型 是 kclient.DockercCli 的 对 象 cli ， 另 一 个 为 类 型 是 
tls.Config 的 对 象 tlsConfig。 定 义 完 变量 之 后 ,， Docker 将 tlsConfig 
的 InsecureSkipVerify 属性 症 为 真 。tlsConfig 对 象 的 创建 是 为 了 保 
障 cli 在 传输 数据 的 时 候 遵 循 安全 传输 层 协 议 ( TLS) 。 安 全 传输 层 协 


议 ( TLS) 用 于 确保 两 个 通信 应 用 程序 之 间 的 保密 性 与 数据 完整 性 
tlsConfig 是 Docker Client 创 建 过 程 中 可 选 的 配置 信息 。 


// If we should verify the server, we need to load a trusted ca 
if *flTLlsVerify { 
*flTls = true 
certPool := x509.NewCertPool() 
file, err := ioutil.ReadFile(*flCa) 
if err != nil { 
log.Fatalf("Couldn't read ca cert %s: %s", *flCa, err) 


certPool .AppendCertsFromPEM(file) 
tlsConfig.RootCAs = certPool 
tlsConfig.InsecureSkipVerify = false 


若 flTlsVerify 这 个 flag 参 数 为 真 ， 则 说 明 Docker Client 需 
Docker Server 一 起 验证 连接 的 安全 性 。 此 时 , tlsConfig 对 象 需要 加 
载 一 个 受信 的 ca 文件 。 该 ca 文件 的 路 径 为 *fICA 人 参数 的 值 ， 最 终 完成 
tlsConfig 对 象 中 RootCAs 属 性 的 赋值 ， 并 将 InsecureSkipVerify 属 
性 站 为 假 。 


// If tls is enabled, try to Load and send client Certificates 
if *fLTLS || *flTLlsVerify { 
_,， errCert := os.Stat(*flCert) 
,， errkey := os.Stat(*flKey) 
if errCert == nil && errkey == nil { 
*flTls = true 
cert, err := tls.LoadX509KeyPair(*flCert, *flKey) 
if err != nil { 
log.Fatalf("Couldn't load X509 key pair: %s. Key encrypted?", err) 


} 
tlsConfig.Certificates = []tls.Certificate{cert} 


如 果 fiTlIs 和 flTlsVerify 两 个 flag 参 数 中 有 一 个 为 真 ， 则 说 明 需 
加 载 并 发 送 客 户 端的 证 书 。 最 终 将 证 书 内 容 交 给 tlsConfig 的 


Certificates 属 性 。 


至 此 , flag 参数 已 经 全 部 处 理 完毕 ，DockerClient 也 已 经 收集 到 
所 需 的 配置 信息 。 下 一 节 将 主要 分 析 如 何 创 建 Docker Client。 


2.2.3 如 何 创 建 Docker Client 


Docker Client 的 创建 其 实 就 是 在 已 有 配置 参数 信息 的 情况 下 ， 
通过 Client 包 中 的 NewDockerCli 方 法 创建 一 个 Docker Clinet 实 例 
cli。 具 体 源码 实现 如 下 : 


if *fLTLS || *flTLlsVerify { 


cli = client.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, 
protoAddrParts[0], protoAddrParts[1], &tlsConfig) } else { 


cli = client.NewDockerCli(os.Stdin, os.Stdout, os.Stderr, 
protoAddrParts[0], protoAddrParts[1], nil) } 


若 flag 参 数 fiTls 为 真 或 者 fiTlsVerify 为 真 ， 则 说 明 需 要 使 用 TLS 
协议 来 保障 传输 的 安全 性 ， 故 创建 Docker Client 的 时 候 ,将 
tlsConfig 参 数 传 入 ; 否则 ,同样 创建 Docker Client , 只 不 过 
tlsConfig 为 nil。 


关于 Client 包 中 的 NewDockerCIli 消 数 的 实现 ,可 以 具体 参 
见 ./docker/api/client/cli.go, 


func NewDockerCli(in io.ReadCloser, out, err io.Writer, proto, addr string, 
tlsConfig *tls.Config) *DockerCli { 


var ( 


isTerminal = false terminalFd uintptr scheme 


if tlsConfig != nil { 


scheme = "https" 


= "http" 


terminalFd = file.Fd() isTerminal = term.IsTerminal(terminalFd) } 


} 
if in != nil { 
if file, ok := out.,(*os.File); ok { 
} 
if err == nil { 
err = out 
} 


return &DockerClif{ 


proto: proto, addr: addr, 


scheme: scheme, } 


in: 
err, isTerminal: isTerminal, terminalFd: terminalFd, tlsConfig: 


in, out: 


out, err: 


tlsConfig, 


总 体 而 言 ， 创 建 DockerCli 对 象 的 过 程 比 较 简单 。 较 为 重要 的 
DockerCli 的 属性 有 : proto ,DockerClient 与 Docker Server 的 传 
输 协议 ; addr ,Docker Client 需 要 访问 的 hos 姐 标 地 址 ; 
tlsConfig ,安全 传输 层 协议 的 配置 。 若 tlsConfig 不 为 空 ， 则 说 明 需 
要 使 用 安全 传输 层 协议 ,DockerCli 对 象 的 scheme 设 置 为 “https”， 
男 外 还 有 关于 输入 、 输 出 以 及 错误 显示 的 配置 等 。 最 终 痕 数 返 回 
DockerCli 对 象 。 


通过 调用 client 包 中 的 NewDockerCli 溪 数 ， 程序 最 终 创建 了 
Docker Client , 返回 main 包 中 的 main 函 数 之 后 ， 程序 继续 往 下 执 


/一 


休 。 


2.3 ”Docker 命 令 执行 


main 昂 数 执行 到 这 个 阶段 ， 有 以 下 内 容 需要 为 Docker 命 令 的 执 
行 服务 : 创建 完毕 的 Docker Client ,docker 命 令 中 的 请 求 参 数 ( 经 
flag 解 析 后 存放 于 flag.Arg( ) ) 。 也 就 是 说 ， 程 序 需 要 使 用 Docker 
Client 来 分 析 Docker 命 令 中 的 请 求 参 数 ， 得 出 请 求 的 类 型 ， 转 义 为 
Docker Server 可 以 识别 的 请 求 之 后 ， 最 终 发 送 给 Docker Server。 


Docker Client 主 要 完成 两 方面 的 工作 : 解析 请 求 命令 ， 得 出 请 
求 类 型 ; 执行 具体 类 型 的 请 求 。 本 节 将 从 这 两 个 方面 深入 分 析 Docker 
Client, 


2.3.1 Docker Client 解 析 请 求 命令 


Docker Client 解 析 请 求 命 令 的 工作 ,在 Docker 命 令 执行 部 分 第 
一 个 完成 。 创 建 Docker Client 之 后 , 回 到 main 响 数 中 ， 继 续 执行 的 
源码 如 下 ( 位 于 ./docker/docker/docker.go#L102-L110) 


if err := cli.Cmd(flag.Args()...); err != nil { 
if sterr, ok := err.(*utils.StatusError); ok { 
if sterr.Status != "" { 
log.Println(sterr.Status) 


0s.Exit(sterr.StatusCode) 


} 
log.Fatal (err) 


学 习 以 上 源码 可 以 发 现 ， 正 如 之 前 所 说 ，Docker Client 首 先 解 
析 存 放 于 flag.Args( ) 中 的 具体 请 求 参数 ， 执 行 的 咀 数 为 cli 对 象 的 
Cmd 函 数 。Cmd 明 数 的 定义 如 下 ( 位 
于 ./docker/api/client/cli.go#L51-L61) 


// Cmd executes the specified command 
func (cli *DockerCli) Cmd(args ...string) error { 
if len(args) > 0 { 
method, exists := cli.getMethod(args[0]) 
if !exists { 
fmt.PrintLn("Error: Command not found:", args[0]) 
return cli.CmdHelp(args[1:]...) 


return method(args[1:]...) 


} 
return cli.CmdHelp(args...) 


由 代码 注释 可 知 ，Cmd 函 数 执行 具体 的 指令 。 在 源码 实现 中 ， 首 
先 判断 请 求 参 数列 表 的 长 度 是 否 大 于 0。 若 长 度 不 大 于 0， 则 说 明 没 有 
请 求 信息 ， 返 回 docker 命 令 的 Help 信 息 ; 若 长 度 大 于 1， 则 说 明 有 请 
求 信 息 ， 那 么 Docker Client 首 先 通 过 请 求 参数 列表 中 的 第 一 个 元 素 
args[0] 来 获取 具体 的 请 求 方法 method。 若 上 述 method 方 法 不 存 
在 ， 则 返回 docker 命 令 的 Help 信 息 ， 若 存在 ， 调 用 具体 的 method 方 
法 , 参数 为 args[1] 及 其 之 后 所 有 的 请 求 参 数 。 


还 是 以 一 个 具体 的 docker 命 令 为 例 , docker-daemon= false-- 
version= false pull Image_Name。 通 过 以 上 Docker Client 的 分 
析 ， 可 以 总 结 出 以 下 执行 流程 。 


1) 解析 flag 参 数 之 后 ，Docker 将 docker 请 求 参 
数 "pull" 和 "Image_Name" 存 放 于 flag.Args( ) 。 


) 创建 好 的 Docker Client 为 cli ,cli 执行 cli.Cmd( flag.Args 
( ) ...) 。 


3) Cmd 郧 数 中 ， 通 过 args[0] 也 就 是 "pull" ,执行 
cli.getMethod( args[0]) ， 获 取 method 的 名 称 。 


4) 在 getMothod 方 法 中 ，Docker 通 过 处 理 最 终 返 回 method 值 
为 "CmdPull", 


5) 最 终 执行 method( args[1 : ]...) 也 就 是 CmdPull 
( args[1 : 1...) 。 


2.3.2 ”Docker Client 执 行 请 求 命 令 


上 一 小 节 通过 一 系列 的 命令 解析 ， 最终 找到 了 具体 的 命令 执行 方 
法 ， 本 小 节 主 要 介绍 Docker Client 如 何 通过 具体 的 执行 方法 ， 处 理 
并 发 送 请 求 。 


不 同 的 Docker 尽 管 请 求 内 容 不 同 ， 但 是 请 求 执行 流程 大 致 相同 ， 
故 本 节 依 旧 以 一 个 例子 来 阐述 其 中 的 流程 ， 例 子 为 : docker pull 
Image_Name。 该 命令 的 作用 为 : DockerClient 发 起 下 载 镜像 的 请 
求 ， 最 终 由 Docker Server 接 收 请 求 ， 由 Docker Daemon 完 成 镜像 
的 下 载 与 存储 。 


Docker Client 在 执行 docker pull Image_Name 请 求 命令 时 ， 
执行 CmdPull 哨 数 ， 传 入 参数 为 args[1 : ]..., 即 Image Name。 源 
码 实 现 位 于 ./docker/api/client/command.go#L1183-L1224. 


下 面 逐一 分 析 CmdPull 的 源码 实现 。 


cmd := cli.Subcmd("pull", "NAME[ :TAG]"， "Pull an image or a repository from the 
registry") 


通过 cli 包 中 的 Subcmd 方 法 定义 一 个 类 型 为 Flagset 的 对 象 


cmd, 


tag := cmd.String([]string{"#t", "#-tag"}, "", "Download tagged image in a 
repository") 


为 cmd 对 象 定义 一 个 类 型 为 String 的 flag ,名 为 "#t" 或 "#- 
tag"， 初 始 值 为 空 ， 目 前 这 个 flag 参 数 基 本 已 经 被 齐 用 。 


if err := cmd.Parse(args); err != nil { 
return nil 
} 


将 args 参 数 进行 第 二 次 flag 参 数 解 析 ， 解析 过 程 中 ， 先 提取 出 是 
否 有 符合 tag 这 个 flag 的 参数 。 若 有 ， 将 其 赋值 给 tag 参 数 ， 其 余 的 参 
数 存 入 cmd.NArg( ) ; 若 没 有 ， 则 将 所 有 的 参数 存 入 cmd.NArg 
( ) 中 。 


if cmd.NArg() != 1 { 
cmd .Usage() 
return nil 


} 


判断 经 过 flag 解 析 后 的 参数 列表 ， 厂 参数 列表 中 参数 的 个 数 不 为 
1 ， 则 说 明 需 要 下 拉 多 个 镜像 或 者 没有 指定 下 拉 镜 像 名 称 ，pull 命 令 均 
不 支持 ， 则 调用 错误 处 理 方法 cmd.Usage( ) ， 并 返回 nil。 


Var ( 
V = url.Values{} 
remote = cmd.Arg(0) 


) 
v.Set(" fromImage ， remote ) 
if *tag == " 

v.Set("tag", *tag) 


创建 一 个 map 类 型 的 变量 v， 该 变量 用 于 存放 下 拉 镜 像 时 所 需 
URL 参 数 ; 随后 将 参数 列表 的 第 一 个 值 cmd.Arg( 0) 赋 给 remote 变 
量 ， 并 将 remote 作 为 键 将 fromlmage 的 值 添加 至 v。 


remote, = parsers,ParseRepositoryTag (remote) 
// Resolve the Repository name from fqn to hostname + name 
hostname, , err := registry.ResolveRepositoryName(remote) 
if err != nil { 

return err 
} 


通过 remote 变 量 首先 得 到 镜像 的 repository 名 称 ， 并 赋 给 
remote 自 身 ， 随 后 通过 解析 改变 后 的 remote， 得 出 镜像 所 在 的 host 
地 址 ， 即 Docker Registry 的 地 址 。 若 用 户 没有 制定 Docker 
Registry 的 地 址 ， 则 Docker 默 认 地 址 为 Docker Hub 地 址 
https://index.docker.io/v1/。 


cli.LoadConfigFile() 
// Resolve the Auth config relevant for this server 
authConfig := cli.configFile.ResolveAuthConfig(hostname) 


通过 cli 对 象 获 取 与 Docker Server 通 信和 所 需要 的 认证 配置 信息 。 


pull := func(authConfig registry.AuthConfig) error { 
buf, err := json.Marshal (authConfig) 
if err != nil { 
return err 


} 
registryAuthHeader := []stringt{ 
base64 .URLEncoding.EncodeToString(buf), 
} 
return cli.stream("POST", "/images/create?"+v.Encode(), nil, cli.out, 
map[string][]string{ 
"X-Registry-Auth": registryAuthHeader, 


}) 
} 


定义 一 个 名 为 pull 的 消 数 ， 传 入 的 参数 类 型 为 
registry.AuthConfig ,返回 类 型 为 error。 销 数 执行 块 中 最 主要 的 内 
容 为 : cli.stream( ...... ) 部 分 。 该 部 分 具体 向 Docker Server 发 送 
POST 请 求 ， 请 求 的 url 为 "/images/create ? "+V.Encode( ) ,请 
求 的 认证 信息 为 : map[string][]string{"X-Registry-Auth": 
registryAuthHeader ，}。 


if err := pull(authConfig); err != nil { 
if strings.Contains(err.Error(), "Status 401") { 
fmt.Fprintln(cli.out, "\nPlease login prior to pull:") 
if err := cli.CmdLogin(hostname); err != nil { 
return err 
} 


authConfig := cli.configFile.ResolveAuthConfig(hostname) 
return pull(authConfig) 


return err 


由 于 上 一 个 步骤 只 是 定义 pull 函 数 ， 这 一 步 又 具体 调用 执行 pull 
蚊 数 ， 实 现实 际 意 义 上 的 下 载 请 求 发 送 。 若 返回 成 功 则 表明 请 求 完 
成 ， 程 序 直接 退出 ， 若 返回 错误 ， 则 做 相应 的 错误 处 理 。 若 返回 错误 
为 401， 则 表示 用 户 下 载 的 镜像 必须 用 户 先 登 录 ， 随即 Docker 
Client 转 至 登录 环节 ， 完 成 之 后 ， 继 续 执行 pull 另 数 ， 若 完成 则 最 终 
返回 。 


青 求 的 全 部 执行 , 其 他 请 求 的 执行 在 流程 上 也 
是 大 同 小 异 。 总 请 求 执行 过 程 中 ， 大 多 都 是 将 命令 行 中 关于 请 求 
的 参数 进行 初步 处 理 ， 并 添加 相应 的 辅助 信息 ， 最 终 通 过 指定 的 协议 


向 Docker Server 发 送 Docker Client 和 Docker Server 约 定好 的 API 
请 求 。 


2.4 总 结 


本 章 从 源码 的 角度 分 析 了 如 何 通过 docker 可 执行 文件 创建 
Docker Client， 最 终 发 送 用 户 请 求 至 Docker Server。 


通过 学 习 与 理解 Docker Client 相 关 的 源码 实现 ， 不 仅 可 以 让 用 
户 熟练 掌握 Docker 命 令 的 使 用 ,还 可 以 使 用 户 在 特殊 情况 下 有 能 力 修 
改 Docker Client 的 源码 ， 使 其 满足 自身 系统 的 某 些 特殊 需求 ， 以 达 
到 定制 Docker Client 的 目的， 最 大 限度 地 发 挥 Docker 开 源 思想 的 价 
值 。 


第 3 章 ”启动 Docker Daemon 


3.1 引言 


自 Docker 延 生 以 来 ， 便 引领 了 轻 量 级 虚拟 化 容 希 领域 的 技术 热 
潮 。 在 这 一 潮流 下 , Google、IBM、Redhat 等 业界 翘楚 纷纷 加 入 
Docker 阵 营 。 虽 然 目前 Docker 仍 主要 基于 Linux 平 台 ， 但 是 
Microsoft 却 多 次 宣布 对 Docker 的 支持 ， 从 先前 宣布 的 Azure 支 持 
Docker 与 Kubernetes ,到 如 今 宣布 的 下 一 代 Windows Server 原 生 
态 支 持 Docker。Microsoft 的 这 一 系列 举措 多 少 喻 示 着 向 Linux 世 界 
的 妥协 ， 当 然 这 也 不 得 不 让 世人 对 Docker 的 巨大 影响 力 有 重新 的 认 


Wh 


Docker 的 影响 力 不 言 而 喻 ,但 如 果 需 要 深入 学 习 Docker 的 内 部 
实现 ， 最 重要 的 就 是 理解 Docker Daemon。 在 Docker 架 构 中 ， 
Docker Client 通 过 特定 的 协议 与 Docker Daemon 进 行 通信 , 而 
Docker Daemon 主 要 承载 了 Docker 运 行 过 程 中 的 大 部 分 工作 。 


Docker Daemon 是 Docker 架 构 中 运行 在 后 台 的 守护 进程 ， 大 
致 可 以 分 为 Docker Server、Engine 和 job 三 部 分 。 三 者 的 关系 大 致 
如 下 : Docker Daemon 通 过 Docker Server 模 块 接 收 Docker 


Client 的 请 求 ， 并 在 Engine 中 处 理 请 求 ， 然 后 根据 请 求 类 型 ， 创建 出 
指定 的 Job 并 运行 。 由 于 用 户 的 请 求 不 同 , DockerDaemon 会 创建 不 
同 的 Job 来 完成 任务 ， 如 : 用 户 发 起 镜像 下 载 请 求 ，DockerDaemon 
创建 名 为 “pull" 的 Job ; 用 户 发 起 启动 容器 的 请 求 ，DockerDaemon 
创建 名 为 “start”" 的 Job...... 


Docker Daemon 的 架构 如 图 3-1 所 示 。 


本 章 从 源码 的 角度 ， 主 要 分 析 Docker Daemon 的 启动 流程 。 由 
于 Docker Daemon 和 Docker Client 的 启动 流程 有 很 多 的 相似 之 
处 ， 故 本 章 不 再 袭 述 Docker Daemon 局 动 的 前 期 工作 、flag 参 数 的 
解析 等 内 容 ， 着重 分 析 Docker Daemon 启 动 流程 中 最 为 重要 的 环 


节 : 创建 Daemon 过 程 中 mainDaemon( ) 的 实现 。 
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图 3-1 DockerDaemon 架 构 示意 图 


3.2 Docker Daemon 的 启动 流程 


Docker Daemon 和 Docker Client 的 启动 均 通过 可 执行 文件 
docker 完 成 ， 因 此 两 者 的 启动 流程 非常 相似 。Docker 可 执行 文件 运 
行 时 ， 程序 运行 通过 不 同 的 命令 行 flag 参 数 ， 区 分 两 者 ， 并 最 终 运 行 
两 者 各 自 相应 的 部 分 。 


启动 Docker Daemon 时 ，, 一般 可 以 使 用 以 下 命令 : docker-- 
daemon=true、docker-d ; dockerd=true 等 。 随 后 由 Docker 的 
main( ) 了 水 数 来 解析 以 上 命令 的 相应 flag 参 数 ， 并 最 终 完 成 Docker 
Daemon 的 启动 。 


首先 , 附 上 Docker Daemon 的 启动 流程 图 ， 如 图 3-2 所 示 。 






< n> 


showVersion'() 


os, Setenv( “Debug” , 1) 


Docker Client 


图 3-2 DockerDaemon 启 动 流程 图 


本 书 第 2 章 已 经 描述 了 Docker 中 main( ) 函数 运行 的 很 多 前 期 
工作 , Docker Daemon 的 启动 也 会 涉及 这 些 工作 ， 故 在 此 略 去 相同 
部 分 ， 主 要 针对 后 续 仅 和 Docker Daemon 相 关 的 内 容 进行 深入 分 


析 , 即 mainDaemon( ) 的 具体 源码 实现 。 


3.3 mainDaemon( ) 的 具体 实现 


Docker Daemon 的 启动 流程 图 展示 了 DockerDaemon 的 从 无 
到 有 。 通 过 分 析 流 程 图 ， 我们 可 以 得 出 一 个 这 样 的 结论 : 区 分 Docker 
Daemon 与 Docker Client 的 关键 在 于 flag 参 数 flDaemon 的 值 。 一 
旦 *flIDaemon 的 值 为 真 ， 则 代表 docker 二 进 制 需 要 启动 的 是 Docker 
Daemon。 有 关 Docker Daemon 的 所 有 的 工作 ,都 被 包含 在 男 数 
mainDaemon( ) 的 具体 实现 中 。 


宏观 来 讲 ,mainDaemon( ) 的 使 命 是 : 创建 一 个 守护 进程 ， 
并 保证 其 正常 运行 。 


从 功能 的 角度 来 说 , mainDaemon( ) 实现 了 两 部 分 内 容 : 第 
一 ,创建 Docker 运 行 环境 ; 第 二 ， 服务 于 Docker Client , 接收 并 处 
理 相应 请 求 ( 完成 Docker Server 的 初始 化 ) 


从 实现 细节 来 分 析 , mainDaemon( ) 的 实现 流程 主要 包含 以 
下 步骤 : 


1) daemon 的 配置 初始 化 。 这 部 分 在 init( ) 盟 数 中 实现 ， 即 在 
mainDaemon( ) 运行 前 就 执行 ,但 由 于 这 部 分 内 容 和 
mainDaemon( ) 的 运行 息息相关 ， 可 以 认为 是 mainDaemon( ) 
运行 的 先决 条 件 。 


2) 命令 行 flag 参 数 检查 。 


创建 engine 对 象 。 


4) 设置 engine 的 信和 号 捕获 及 处 理 方法 。 


dh 


加 载 builtins。 


C2) 


使 用 goroutine 加 载 daemon 对 象 并 运行 。 


打 Ej Docker 版 本 及 驱动 信息 。 


> 


8) serveapi 的 创建 与 运行 。 


对 于 以 上 内 容 ,本 章 将 一 一 深入 分 析 。 


3.3.1 配置 初始 化 


mainDaemon( ) 的 运行 位 
于 ./docker/docker/docker/daemon.go , 深入 分 析 mainDaemon 
( ) 的 实现 之 前 ， 我 们 回 到 Go 语言 的 特性 ， 即 变量 与 init 约 数 的 执行 
顺序 。 在 daemon.go 中 ，Docker 定 义 了 变量 daemonCfg , 以 及 init 
纯 数 ， 通 过 Go 语言 的 特性 ， 变 量 的 定义 与 init 多 数 均 会 在 
mainDaemon( ) 之 前 运行 。 两 者 的 定义 如 下 : 


var ( 
daemonCfg = &daemon.Config{} 


func init() { 
daemonCfg.InstallFlags() 


首先 ，Docker 声 明 一 个 名 为 daemonCfg 的 变量 ， 代表 整个 
Docker Daemon 的 配置 信息 。 定 义 完 毕 之 后 ,init 约 数 的 存在 ,使 
得 daemonCfg 变 量 能 获取 相应 的 属性 值 。 在 Docker Daemon 月 动 
时 ,daemonCfg 变 量 被 传递 至 Docker Daemon 并 被 使 用 。 


Config 对 象 的 定义 如 下 ( 含 部 分 属性 的 解释 ) ， 该 对 象 位 
于 ./dockervdockervdaemon/config.go : 


type Config struct { 
Pidfile string //Docker Daemon 所 属 进程 的 PID 文 件 
Root string //Docker 运 行 时 所 使 用 的 root 路 径 
AutoRestart bool // 是 否 一 直 支 持 创建 容器 的 重启 


Dns []string//DockerDaemon 为 容器 准备 的 DNS Server 地 址 


DnsSearch []string//Docker 使 用 的 指定 的 DNS 查 找 地 址 
Mirrors []string// 指 定 的 Docker Registry 镜 像 地 址 
EnableIptables bool // 是 否 启用 Docker 的 iptabLes 功 能 
EnabLeIpForward bool // 是 否 启 用 net .ipv4.ip forward 功能 
EnableIpMasq bool // 启 用 IP 伪 装 技术 

DefaultIp net .IP  // 绑 定 容 器 端口 时 使 用 的 默认 IP 
BridgeIface string // 添 加 容器 网 络 至 已 有 的 网 桥接 口 名 
BridgeIP string // 创 建 网 桥 的 TP 地 址 

FixedCIDR string  // 指 定 IP 的 IPv4 子 网 ， 必 须 被 网 桥 子 网 包含 
InterContainerCommunication bool // 是 否 允 许 宿主 机 上 Docker 容 器 间 的 通信 
GraphDriver string //Docker Daemon 运 行 时 使 用 的 特定 存储 驱动 
GraphOptions []string// 可 设置 的 存储 驱动 选项 

ExecDriver string //Docker 运 行 时 使 用 的 特定 exec 驱 动 

Mtu int // 设 置 容 颖 网 络 接口 的 MTU 
DisableNetwork bool // 是 否 支持 Docker 容 器 的 网 络 模 式 
EnableSelinuxSupport bool // 是 否 局 用 对 SELinux 功 能 的 支持 
Context map[string][]string 


Docker 声 明 daemoncCfg 之 后 ,init 级 数 实现 了 daemoncCfg 变 
量 中 各 属性 的 赋值 具体 的 实现 为 : daemonCfg.InstallFlags 
( ) ,位 于 ./dockerdockervdaemon/config.go ,代码 如 下 : 


func (config *Config) InstaLLFLags() { 

flag.StringVar(&config.Pidfile, []string{"p", "-pidfile"}, 
"/var/run/docker.pid", "Path to use for daemon PID file") 

flag.StringVar(&config.Root, []string{"g", "-graph"}, 
"/var/lib/docker", "Path to use as the root of the Docker runtime") 

flag.BoolVar(&config.AutoRestart, []string{"#r", "#-restart"}, true, "- 
-restart on the daemon has been deprecated infavor of --restart policies on 
docker run") 

flag.BoolVar(&config.EnableIlptables, []string{"#iptables", "- 
iptables"}, true, "Enable Docker's addition of iptables rules") 


flag.BoolVar(&config.EnableIpForward, []string{"#ip-forward", "-ip- 
forward"}, true, "Enable net.ipv4.ip forward") 

flag.StringVar(&config.BridgeIpP, []string{"#bip", "-bip"}, "", "Use 
this CIDR notation address for the network bridge's IP, not compatible with -b") 

flag.StringVar(&config.BridgeIlface, []string{"b", "-bridge"}, "", 


"Attach containers to a pre-existing network bridge\nuse 'none' to disable 
container networking") 

flag.BoolVar(&config.InterContainerCommunication, []string{"#icc", "- 
icc"}, true, "Enable inter-container communication") 

flag.StringVar(&config.GraphDriver, []string{"s", "-storage-driver"}, 
"", "Force the Docker runtime to use a Specific storage driver") 

flag.StringVar(&config.ExecDriver, []string{"e", "-exec-driver"}, 
"native", "Force the Docker runtime to use a specific exec driver") 

flag.BoolVar(&config.EnableSelinuxSupport, []string{"-selinux- 
enabled"}, false, "Enable selinux support. SELinux does not presently support the 
BTRFS storage driver") 

flag.IntVar(&config.Mtu, []string{"#mtuyu", "-mtu"}, 0, "Set the 
containers network MTU\nif no value is provided: default to the default route MTU 
or 1500 if no default route is available") 


opts.IPVar(&config.DefaultIp, []string{"#ip", "-ip"}, "0.0.0.0", 
Default IP address to use when binding container ports") 
pts.ListVar(&config.GraphOptions, []string{"-storage-opt"}, "Set 


storage driver options") 
// FIXME: why the inconsistency between "hosts" and "sockets"? 
i "-dns"}, "Force Docker to 


opts.IPListVar(&config.Dns, []string{"#dns", 
use specific DNS servers") 
opts.DnsSearchListVar(&config.DnsSearch, []string{"-dns-search"}, 
Force Docker to use specific DNS search domains" 


在 函数 InstallFlags( ) 的 实现 过 程 中 ，Docker 主 要 定义 了 众多 


类 型 不 一 的 flag 参 数 ， 并 将 该 参数 的 值 绑 定 在 daemonCfg 变 量 的 指 


» 


-大 
定 属性 上 , 如: 


"-pidfile"}, "/var/run/docker.pid", 


flag.StringVar(&config.Pidfile, []string{"p", 
"Path to use for daemon PID file") 


以 上 语句 的 含义 为 : 


:定义 一 个 String 类 型 的 flag 参 数 。 


该 flag 的 名 称 为 "p" 或 者 "-pidfile"。 


该 flag 的 默认 值 为 "/var/run/docker.pid"， 并 将 该 值 绪 定 在 变 


量 config.Pidfile 上 。 


flag 的 描述 信息 为 "Path to use for daemon PID file"。 


至 此 ,关于 Docker Daemon 所 需要 的 配置 信息 均 声 明 并 初始 化 


毕 。 


di} 


3.3.2 ”flag 参数 检查 


从 本 小 节 开始 ， 程 序 运行 真正 进入 Docker Daemon 的 
mainDaemon( ) ， 下面 对 此 流程 进行 深入 分 析 。 


mainDaemon( ) 运行 的 第 一 个 步 又 是 命令 行 flag 参 数 的 检 
查 。 具 体 而 言 , 即 当 docker 命 令 经 过 flag 参 数 解 析 之 后 ，Docker 判 
断 剩 余 的 参数 是 否 为 0。 若 为 0， 则 说 明 Docker Daemon 的 启动 命令 
无 误 ， 正常 运行 ; 若 不 为 0， 则 说 明 在 启动 Docker Daemon 的 时 
候 ，, 传 入 了 多 余 的 参数 ， 此 时 Docker 会 输出 错误 提示 ， 并 退出 运行 程 
序 。 具 体 代码 如 下 : 


if flag.NArg() != 0 { 
flag.Usage() 
return 


3.3.3 创建 engine 对 象 


在 mainDaemon( ) 运行 过 程 中 , fag 参数 检查 完毕 之 后 ， 
Docker 随 即 创 建 engine 对 象 ， 代 码 如 下 : 


eng := engine.New() 


Engine 是 Docker 染 构 中 的 运行 引擎 ， 同 时 也 是 Docker 运 行 的 核 
心 模块 。Engine 扮 演 着 Docker Container 存 储 仓库 的 角色 ， 并 且 通 
过 Job 的 形式 管理 Docker 运 行 中 涉及 的 所 有 任务 。 


Engine 结 构 体 的 定义 位 
于 ./dockerdockerengine/engine.go#L47-L60， 具体 代 码 如 


下 : 


type Engine struct { 


handlers 
catchall 
hack 

id 
Stdout 
Stderr 
Stdin 
Logging 
tasks 

L 


shutdown 


map[string]Handler 

Handler 

Hack // data for temporary hackery (see hack.go) 
string 

io.Writer 

io.Writer 

io.Reader 

bool 

sync.WaitGroup 

sync.RWMutex // lock for shutdown 
bool 


onShutdown []func() // shutdown handlers 


Engine 结 构 体 中 最 为 重要 的 是 handlers 属 性 ，handlers 属 性 为 
map 类 型 ，key 的 类 型 是 string , Value 的 类 型 是 Handler。 其 中 
Handler 类 型 的 定义 位 
于 ./docker/docker/engine/engine.go#L23 ,具体 代码 如 下 : 


type Handler func(*Job) Status 


可 网 ，Handler 为 一 个 定义 的 限 数 。 该 函数 传 入 的 参数 为 Job 指 
针 ， 返回 为 Status 状 态 。 


了 解 完 Engine 以 及 Handler 的 基本 知识 之 后 ， 我 们 真正 进入 创建 
Engine 实 例 的 部 分 ， 即 New( ) 函数 的 实现 ， 有 具体 代码 如 下 : 


func New() *Engine { 
eng := &Enginet{ 

handlers: make(map[string]Handler), 
id: utils.RandomString(), 
Stdout: os.Stdout, 
Stderr: os.Stderr, 
Stdin: os.Stdin, 
Logging: true, 


} 
eng.Register("commands", func(job *Job) Status { 
for , name := range eng.commands() { 
job.Printf("%s\n", name) 
return StatusOK 
}) 


// Copy existing global handlers 
for k, v := range globalHandlers { 
eng.handlers[k] = V 


return eng 


分 析 以 上 代码 ， 从 返回 结果 可 以 发 现 ， New( ) 上 另 数 最 终 返 回 一 
个 Engine 实 例 对 象 。 而 在 代码 实现 部 分 ， 大致 可 以 将 其 分 为 三 个 步 


又 : 


1) 创建 一 个 Engine 结 构 体 实例 eng ,并 初始 化 部 分 属性 ,如 
handlers、id、 标 准 输 出 stdout. 日 志 属 性 Logging 等 。 


) 向 eng 对 象 注册 名 为 commands 的 Handler , 其 中 Handler 
为 临时 定义 的 函数 func( job*Job) Status{}+， 该 函数 的 作用 是 通过 
job 来 打印 所 有 已 经 注册 完毕 的 command 名 称 ， 最 终 返回 状态 
StatusOkK。 


) 将 变量 globalHandlers 中 定义 完毕 的 所 有 Handler 都 复制 到 
eng 对 象 的 handlers 属 性 中 。 


至 此 ， 一 个 基本 的 Engine 对 象 实例 eng 已 经 创建 完毕 ， 并 实现 部 
分 属性 的 初始 化 。Docker Daemon 启 动 的 后 续 过 程 中 ， 仍 然 会 对 
Engine 对 象 实例 进行 额外 的 配置 。 


3.3.4 设置 engine 的 信号 捕获 


Docker 在 包 engine 中 执行 完 Engine 对 象 的 创建 与 初始 化 之 后 ， 
回 到 mainDaemon( ) 函数 的 运行 ， 紧 接着 执行 的 代码 为 : 


signaL.Trap(eng.Shutdown) 


Docker Daemon 作 为 Linux 操 作 系统 上 的 一 个 后 台 进 程 ， 原 则 
上 应 该 具备 处 理 信 号 的 能 力 。 信 和 号 处 理 能 力 的 存在 ， 能 保障 Docker 管 
理 员 可 以 通过 向 Docker Daemon 发 送信 号 的 方式 ， 管 理 Docker 
Daemon 的 运行 。 

再 来 看 以 上 代码 则 不 难 理解 其 中 的 含义 : 在 Docker Daemon 的 
运行 中 ， 设 置 捕获 特定 信号 后 的 处 理 方法 ， 特 定 信 号 有 SIGINT、 
SIGTERM 以 及 SIGQUIT ; 当 程 序 捕 获 SIGINT 或 者 SIGTERM 信 和 号 时 ， 
执行 相应 的 善后 操作 ， 最 后 保证 Docker Daemon 程序 退出 。 

该 部 分 代码 的 实现 位 于 ./docker/docker/pkg/signal/trap.go。 


实现 的 流程 分 为 以 下 4 个 步 又 : 


1) 创建 并 设置 一 个 channel , 用 于 发 送信 号 通知 。 


2) 定义 signals 数 组 变量 ， 初 始 值 为 os.SIGINT ， 
os.SIGTERM ; 若 环境 变量 DEBUG 为 空 ， 则 添加 os.SIGQUIT 至 
signals 数 组 。 


3) 通过 gosignal.Notify( c，, signals...) 中 Notify 卫 数 来 实现 
将 接收 到 的 signal 信 号 传递 给 c。 需 要 注意 的 是 只 有 signals 中 被 罗列 
出 的 信号 才 会 被 传递 给 c， 其 余 信号 会 被 直接 忽略 。 


4) 创建 一 个 goroutine 来 处 理 具体 的 signal 信 号 ， 当 信号 类 型 为 
os.Interrupt 或 者 syscall.SIGTERM 时 ， 执 行 传 入 Trap 函 数 的 具体 执 
行 方法 ， 形 参 为 cleanup( ) ， 实 参 为 eng.Shutdown.。 


Shutdown( ) 辫 数 的 定义 位 
于 ./docker/docker/engine/engine.go#L153-L199 ,主要 完成 的 
任务 是 : Docker Daemon 关 闭 时 ,做 一 些 必 要 的 善后 工作 。 


善后 工作 主要 有 以 下 4 项 : 
.Docker Daemon 不 再 接受 任何 新 的 job。 
.Docker Daemon 等 待 所 有 存活 的 job 执行 完毕 。 


.Docker Daemon 调 用 所 有 shutdown 的 处 理 方法 。 


.在 15 秒 时 间 内 , 若 所 有 的 handler 执 行 完 毕 , 则 Shutdown( ) 
消 数 返回 ， 否 则 强制 返回 。 


由 于 在 signal.Trap( eng.Shutdown) 函数 的 具体 实现 中 ,一 
有 旦 程序 接收 到 相应 的 信号 ， 则 会 执行 eng.Shutdown 这 个 函数 ， 在 执 
行 完 eng.Shutdown 之 后 ,随即 执行 os.Exi 0) ， 完 成 当前 整个 
Docker Daemon 程 序 的 退出 。 源 码 实现 位 
于 ./docker/docker/pkg/signal/trap.go#L33-L47。 


3.3.5 ”加载 builtins 


DockerDaemon 设 置 完 Trap 特 定 信 号 的 处 理 方法 ( 即 
eng.shutdown( ) 哨 数 ) 之 后 ,Docker Daemon 实 现 了 builtins 
的 加 载 。 Docker 的 builtins 可 以 理解 为 : Docker Daemon 运行 过 程 
中 ,注册 的 一 些 任务 ( job) ， 这 部 分 任务 一 般 与 容 希 的 运行 无 关 ， 
与 Docker Daemon 的 运行 时 信息 有 关 。 加 载 builtins 的 源码 实现 如 
下 : 


if err := builtins.Register(eng); err != nil { 
log.Fatal (err) 


加 载 builtins 完 成 的 具体 工作 是 : 向 engine 注 册 多 个 Handler ， 
以 便 后 续 在 执行 相应 任务 时 ， 运行 指定 的 Handler。 这 些 Handler 包 
括 : Docker Daemon 和 宿主 机 的 网 络 初始 化 、Web API 服 务 、 事 件 查 
询 、 版 本 查看 、Docker Registry 的 验证 与 搜索 等 。 源 码 实 现 位 
于 ./docker/docker/builtins/builtins.go#L16-L30 , 如 下 : 


func Register(eng *engine.Engine) error { 


if err := daemon(eng); err != nil { 
return err 

} 

if err := remote(eng); err != nil { 
return err 

} 

if err := events.New().Install(eng); err != nil { 
return err 

} 


if err := eng.Register("version", dockerVersion); err != nil { 


return err 


} 
return registry.NewService().Install (eng) 


下 面 分 析 Register 溪 数 实现 过 程 中 最 为 主要 的 5 个 部 分 : 
daemon( eng) 、remote( eng) 、events.New( ) .Install 
( eng) 、eng.Register( "version", dockerVersion) 以 及 


registry.NewService( ) .Install( eng) 。 
1. 注 册 网 络 初始 化 处 理 方法 


daemon( eng) 的 实现 过 程 ,， 主要 为 eng 对 象 注册 了 一 个 键 
为 "init_networkdriver" 的 处 理 方法 ， 此 处 理 方法 的 值 为 
bridge.InitDriven 溪 数 ， 源码 如 下 : 


func daemon(eng *engine.Engine) error { 
return eng.Register("init networkdriver", bridge.InitDriver) 


需要 注意 的 是 ,向 eng 对 象 注册 处 理 方法 ， 并 不 代表 处 理 方法 的 
值 明 数 会 被 立即 调用 执行 ， 如 注册 init_networkdrive 时 
bridge.InitDriver 并 不 会 直接 运行 ， 而 是 将 bridge.InitDriver 的 纯 数 
人 入口 作为 init _ networkdriver 的 值 , 写 入 eng 的 handlers 属 性 中 。 当 
Docker Daemon 接 收 到 名 为 init_networkdriver 的 job 的 执行 请 求 
时 ,bridge.InitDriver 才 被 Docker Daemon 调 用 执行 。 


Bridge.InitDriver 的 具体 实现 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#7 
9-L175 ,主要 作用 为 : 


获取 为 Docker 服 务 的 网 络 设备 地 址 。 
:创建 指定 IP 地 址 的 网 桥 。 
:配置 网 络 iptables 规 则 。 


` 男 外 还 为 eng 对 象 注册 了 多 个 Handler , 如 
allocate interface、release interface、allocate port 以 及 link 


re 


本 书 将 在 第 6 章 详细 分 析 Docker Daemon 如 何 初始 化 簿 主机 的 
网 络 环境 。 


2. 注 册 API 服 务 处 理 方 法 


remote( eng) 的 实现 过 程 ， 主 要 为 eng 对 象 注册 了 两 个 
Handler , 分 别 为 serveapi 与 acceptconnections ,源码 实现 如 
下 : 

func remote (eng *engine.Engine) error { 


if err := eng.Register("serveapi", apiserver.ServeApi); err != nil { 
return err 


return eng.Register("acceptconnections", apiserver.AcceptConnections) 


注册 的 两 个 处 理 方法 名 称 分 别 为 Serveapi 与 
acceptconnections， 相 应 的 执行 方法 分 别 为 apiserver.ServeApi 
与 apiserver.AcceptConnections ,具体 实现 位 
于 ./docker/docker/api/server/server.g0o。 其 中 ，ServeApi 执 行 
时 ， 通过 循环 多 种 指定 协议 ， 创建 出 goroutine 协 调 来 配置 指定 的 
http.Server, 最终 为 不 同 协议 的 请 求 服务 ; 而 AcceptConnections 
的 作用 主要 是 : 通知 宿主 机 上 init 守 护 进程 Docker Daemon 已 经 启 
动 完 毕 ， 可 以 让 Docker Daemon 开 始 服务 API 请 求 。 


3 .注册 events 事 件 处 理 方法 


events.New( ) .Install( eng) 的 实现 过 程 ， 为 Docker 注 册 
了 多 个 event 事 件 ， 功 能 是 给 Docker 用 户 提供 API ,使 得 用 户 可 以 通 
过 这 些 API 查 看 Docker 内 部 的 events 信 息 ，log 信 息 以 及 
subscribers_count 人 信息。 具体 的 源码 位 
于 ./docker/docker/events/events.go#L29-L42 ,如 下 所 示 : 


func (e *Events) Install(eng *engine.Engine) error { 

jobs := map[lstring]jengine.Handlert{ 
"events": e.Get, 
"log": e.Log, 
"subscribers count": e,9ubscribersCount， 

} 

for name, job := range jobs { 
if err := eng.Register(name, job); err != nil { 

return err 


} 


return nil 


4. 注 册 版 本 处 理 方法 


eng.Register( "version", dockerversiom) 的 实现 过 程 ， 向 
eng 对 象 注册 key 为 version , value 为 dockerVersion 执 行 方 法 的 
Handler。dockerVersion 的 执行 过 程 中 ， 会 向 名 为 version 的 Job 的 
标准 输出 中 与 入 Docker 的 版 本 、Docker API 的 版 本 、git 版 本 、Go 
语言 运行 时 版 本 ， 以 及 操作 系统 版 本 等 信息 。dockerVersion 的 源码 
实现 如 下 : 


func dockerVersion(job *engine.Job) engine.Status { 
Vv := &engine.Env{} 
Vv.SetJson("Version", dockerversion.VERSION) 
Vv.SetJson("ApiVersion", api.APIVERSION) 
Vv.Set("GitCommit", dockerversion.GITCOMMIT) 
VvV.Set("GoVersion", runtime.Version()) 
Vv.Set("0s", runtime.GO0S) 
v.Set("Arch", runtime,.GOARCH) 
if kernelVersion, err := kernel.GetKernelVersion(); err == nil { 
v.Set("KernelVersion", kernelVersion.String()) 


if , err := VvV.WriteTo(job.Stdout); err != nil { 


return job.Error(err) 


return engine.StatusOK 


5. 注 册 registry 处 理 方法 


registry.NewService( ) .Install( eng) 的 实现 过 程 位 
于 ./dockerdockerregistry/service.go ,功能 是 : 在 eng 对 象 对 外 
暴露 的 API 信 息 中 添加 docker registry 的 信息 。 若 
registry.NewService( ) 被 成 功 安装 ， 则 会 有 两 个 相应 的 处 理 方法 
注册 至 eng , Docker Daemon 通 过 Docker Client 提 供 的 认证 信息 


向 registry 发 起 认证 请 求 ; search ,在 公有 registry 上 搜索 指定 的 镜 
像 ,目前 公有 的 registry 只 支持 Docker Hub。 


Install 的 具体 实现 如 下 : 


func (s *Service) Install(eng *engine.Engine) error { 
eng.Register("auth", s.Auth) 
eng.Register("search", s.Search) 
return nil 


至 此 , Docker Daemon 所 有 builtins 的 加 载 全 部 完成 ， 实 现 了 
向 eng 对 象 注册 特定 的 处 理 方法 。 


3.3.6 使 用 goroutine 加 载 daemon 对 象 并 运行 


Docker 执 行 完 builtins 的 加 载 之 后 ， 再 次 回 到 mainDaemon 
( ) 的 执行 流程 中 。 此 时 ，Docker 通 过 一 个 goroutine 协 程 加 载 
daemon 对 象 并 开始 运行 Docker Server。 这 一 环节 的 执行 ， 主要 包 
含 以 下 三 个 步骤 : 


1) 通过 init 缠 数 中 初始 化 的 daemonCfg 与 eng 对 象 ， 创 建 一 个 
daemon 对 象 d 。 


2) 通过 daemon 对 象 的 Install 钢 数 ， 向 eng 对 象 中 注册 众多 的 
处 理 方法 。 


3) 在 Docker Daemon 启 动 完毕 之 后 ， 运行 名 为 
acceptconnections 的 Job， 主要 工作 为 向 init 守 护 进 程 发 送 
READY= 1 信号 ， 以 便 Docker Server 开 始 正 常 接收 请 求 。 


源码 实现 位 于 ./docker/docker/docker/daemon.go#L43- 
L56 , 如 下 所 示 : 


go func() { 
d, err := daemon.MainDaemon (daemonCfg, eng) 
if err != nil 
log.Fatal (err) 
} 


if err := d.Install(eng); err != nil { 
log.Fatal (err) 
} 


if err := eng.Job("acceptconnections").Run(); err != nil { 
log.Fatal (err) 


下 面 详细 分 析 三 个 步 又 所 做 的 工作 。 
1 .创建 daemon 对 象 


daemon.NewDaemon( daemonCfg , eng) 是 创建 daemon 
对 象 d 的 核心 部 分 ， 主 要 作用 是 初始 化 Docker Daemon 的 基本 环 
境 ， 如 处 理 config 参 数 ， 验 证 系统 支持 度 ， 配置 Docker 工 作 目 录 ， 
设置 与 加 载 多 种 驱动 ,创建 graph 环 境 ,验证 DNS 配置 等 。 


由 于 daemon.MainDaemon( daemonCfg , eng) 是 加 载 
Docker Daemon 的 核心 部 分 , 且 篇 幅 过 长 ， 本 书 第 4 章 将 深入 分 析 
NewDaemon 的 实现 。 


2. 通 过 daemon 对 象 为 engine 注 册 Handler 


Docker 创 建 完 daemon 对 象 ，goroutine 立 即 执行 d.Install 
( eng) ,具体 实现 位 于 ./dockerdaemon/daemon.go，, 代码 如 下 
所 示 : 


func (daemon *Daemon) Install(eng *engine.Engine) error { 


for name, method := range map[string]jengine.Handlert{ 
"attach": daemon.ContainerAttach, 
"build": daemon.CmdBuild, 
"commit": daemon .ContainerCommit, 
"container changes": daemon.ContainerChanges, 
"container copy": daemon.ContainerCopy, 


"container inspect": daemon.ContainerInspect, 


"containers": daemon.Containers, 


"create": daemon.ContainerCreate, 
"delete": daemon .ContainerDestroy, 
"export": daemon.ContainerExport, 
"info": daemon.CmdInfo， 
"kill": daemon.ContainerKill, 
"image delete": daemon.ImageDelete, 

} 1{ 
if err := eng.Register(name, method); err != nil { 

return err 

} 

} 

if err := daemon.Repositories().Install(eng); err != nil { 
return err 


} 
eng.Hack SetGlobalVar("httpapi.daemon", daemon) 
return nil 


以 上 代码 的 实现 同样 分 为 三 部 分 : 
:向 eng 对 象 中 注册 众多 的 处 理 方法 对 象 。 


‘daemon.Repositories( ) .Install( eng) 实现 了 向 eng 对 象 
注册 多 个 与 Docker 镜 像 相关 的 Handler , Install 的 实现 位 
于 ./docker/docker/graph/service.go。 


‘eng.Hack SetGlobalVar( "httpapi.daemon" , daemon) 
实现 向 eng 对 象 中 类 型 为 map 的 hack 对 象 中 添加 一 条 记录 ， 键 为 
httpapi.daemon , 值 为 daemon。 


3. 运 行 名 为 acceptconnections 的 job 


Docker 在 goroutine 的 最 后 环节 运行 名 为 acceptconnections 


的 Job， 主 要 作用 是 通知 init 守 护 进程 ,使 Docker Daemon 开 始 接受 


请 求 。 源 码 位 于 ./docker/docker/docker/daemon.go#L53-L55 ， 
如 下 所 示 : 


// after the daemon is done setting up we can tell the api to start 

// accepting connections 

if err := eng.Job("acceptconnections").Run(); err != nil { 
log.Fatal (err) 


关于 job 的 运行 流程 大 同 小 异 ， 总结 而 言 ， 都 是 首先 创建 特定 名 
称 的 Job， 其 次 为 Job 配 置 环境 参数 ， 最 后 运行 J]ob 对 应 Handler 的 独 
数 。 作 为 本 书 涉及 的 第 一 个 具体 Job , 下面 将 对 acceptconnections 
这 个 Job 的 执行 进程 深入 分 析 。 


eng.jJob( "acceptconnections") .Run( ) 的 运行 包含 两 部 
分 : 首先 执行 eng.JjJob( "acceptconnections") ,返回 一 个 Job 实 
例 ， 随 后 再 执行 该 job 实例 的 Run( ) 函数 。 


eng.jJob( "acceptconnections") 的 实现 位 


于 ./docker/docker/engine/engine.go#L115-L137 ,如 下 所 示 : 


func (eng *Engine) Job(name string, args ...string) *Job { 
job := &Jjob{ 
Eng: eng, 
Name: name, 
Args: args, 
Stdin: NewInput()， 
Stdout: NewOutput(), 
Stderr: NewOutput(), 
env: S&Env{}, 


} 
if eng.Logging { 
job.Stderr.Add(utils.NopWriteCloser(eng.Stderr)) 


} 
if handler, exists := eng.handlers[name]; exists { 


job .handLer = handler 
} else if eng.catchall != nil && name != "" { 
job.handler = eng.catchall 


return job 


} 


通过 分 析 以 上 创建 job 的 源码 ， 我 们 可 以 发 现 Docker 首 先 创建 一 
个 类 型 为 job 的 job 对 象 ， 该 对 象 中 Eng 属 性 为 另 数 的 调用 者 eng ,该 
对 象 的 Name 属 性 为 acceptconnections， 没有 其 他 参数 传 入 。 另 外 
在 eng 对 象 所 有 的 handlers 属 性 中 寻找 Key 为 acceptconnections 所 
对 应 的 value 值 ( 即 具体 的 Handler) 。 由 于 在 加 载 builtins 时 ， 源 码 
remote( eng) 已 经 向 eng 注 册 过 这 样 一 条 记录 ， 键 为 
acceptconnections , 值 为 apiserverAcceptConnections。 
此 ,Job 对象 的 handler 属 性 为 apiserverAcceptConnections。 最 
后 函数 返回 已 经 初始 化 完毕 的 对 象 Job。 


创建 完 job 对 象 之 后 ， 随 即 执行 该 job 对 象 的 run( ) 函数 。run 
( ) 函数 的 源码 实现 位 于 ./docker/docker/engine/job.go#L48- 
L96 ,该 函数 执行 指定 的 Job， 并 在 Job 执 行 完 成 前 一 直 处 于 阻塞 状 
态 。 对 于 名 为 acceptconnections 的 job 对 象 ， 运 行 代码 为 
job.status= job.handler( job) ,由 于 job.handler 值 为 
apiserverAcceptConnections , 故 真 正 执行 的 是 


job.status= apiserverAcceptConnections( job) 。 


AcceptConnections 的 具体 实现 属于 Docker Server 的 范畴 ， 
深入 研究 Docker Server 可 以 发 现 ， 这 部 分 源码 位 
于 ./docker/docker/api/server/server.go#L1370-L1380 , 如 下 所 
不 : 
func AcceptConnections(job *engine.Job) engine.Status { 
// Tell the init daemon we are accepting requests 
go systemd.SdNotify("READY=1") 


if activationLock != nil { 
close(activationLock) 


return engine.StatusOK 


AcceptConnections 上 函数 的 重点 是 go systemd.SdNotify 
(“"READY=1") 的 实现 , 位 
于 ./docker/docker/pkg/system/sdnotify.go#L12-L33 ,主要 作用 
是 通知 init 守 护 进 程 Docker Daemon 的 启动 已 经 全 部 完成 ， 港 在 的 
功能 是 要 求 Docker Daemon 开 始 接收 并 服务 Docker Client 发 送 来 
的 API 请 求 。 


至 此 ， 通 过 goroutine 来 加 载 daemon 对 象 并 运行 局 动 Docker 
Server 的 工作 全 部 完成 。 


3.3.7 打印 Docker 版 本 及 驱动 信息 


Docker 再 次 回 到 mainDaemon( ) 的 运行 流程 ,由 于 Go 语言 
goroutine 的 性 质 ,在 goroutine 执 行 之 时 , mainDaemon( ) 函数 
内 部 其 他 代码 也 会 并 发 执行 。 


第 一 个 执行 的 即 为 显示 Docker 的 版 本 信息 、GitCommit 信 息 、 
ExecDriver 和 GraphDriver 这 两 个 驱动 的 具体 信息 ， 源 码 如 下 : 


log.Printf("docker daemon: %s %s; execdriver: %s; graphdriver: %s", 
dockerversion.VERSION, 
dockerversion.GITCOMMIT, 
daemonCfg.ExecDriver, 
daemonCfg.GraphDriver, 


) 


3.3.8 ”serveapi 的 创建 与 运行 


打印 Docker 的 部 分 具体 信息 之 后 ,Docker Daemon 立 即 创建 
并 运行 名 为 serveapi 的 Job， 主 要 作用 为 让 Docker Daemon 提 供 
Docker Client 发 起 的 API 服 务 。 实 现代 码 位 
于 ./docker/docker/docker/daemon.go#L66 ,如 下 所 示 : 


job := eng.Job("serveapi", flHosts...) 
job.SetenvBool ("Logging", true) 
job.SetenvBool ("EnableCors", *flEnableCors) 
job.Setenv("Version", dockerversion.VERSION) 
job.Setenv("SocketGroup", *flSocketGroup) 
job.SetenvBool ("Tls", *f1lTls) 
job.SetenvBool ("TlsVerify", *flTlsVerify) 
job.Setenv("TlsCa", *flCa) 
job.Setenv("TlsCert", *flCert) 
job.Setenv("TlsKey", *flkKey) 
job.SetenvBool ("BufferRequests", true) 
if err := job.Run(); err != nil { 

log.Fatal (err) 


以 上 代码 标志 着 Docker Daemon 真 正 进 入 状态 。 实 现 过 程 中 ， 
Docker 首 先 创建 一 个 名 为 serveapi 的 Job， 并 将 flHosts 的 值 赋 给 
job.Args。flHosts 的 作用 主要 是 : 为 Docker Daemon 提 供 使 用 的 
协议 与 监听 的 地 址 。 随 后 ，Docker Daemon 为 该 job 设置 了 众多 的 
环境 变量 ， 如 安全 传输 层 协议 的 环境 变量 等 。 最 后 通过 job.Run( ) 
运行 该 Serveapi 的 Job。 


由 于 在 eng 中 key 为 serveapi 的 handler , value 为 
apiserverServeApi , 故 该 job 运行 时 , 执行 apiserverServeAp 衣 
数 ， 位于./dockerdockerapi/serverservergo。ServeApi 函 数 的 
作用 是 : 对 于 所 有 用 户 定 义 支 持 协议 ，Docker Daemon 均 创建 一 个 
goroutine 来 启动 相应 的 http.Server , 并 为 每 一 种 协议 服务 。 


由 于 创建 并 启动 http.Server 为 Docker 架 构 中 有 关 Docker 
Server 的 重要 内 容 ,本 书 将 在 第 5 章 深 入 介绍 Docker Server。 


至 此 , 我 们 可 以 认为 Docker Daemon 已 经 完成 了 serveapi 这 个 
job 的 初始 化 工作 。 一 旦 acceptconnections 这 个 Job 运 行 完毕 ， 
Docker Daemon 则 会 通知 init 进 程 Docker Daemon 启 动 完毕 ,可 


以 开始 提供 API 服 务 ， 两 个 job 通过 activationLock 进 行 同步 。 


3.4 总 结 


本 章 从 源码 的 角度 分 析 了 Docker Daemon 的 局 动 ， 着 重 分 析 了 


mainDaemon( ) 的 实现 。 


Docker Daemon 作 为 Docker 架 构 中 的 主干 部 分 ， 负责 
Docker 内 部 几乎 所 有 操作 的 管理 。 学 习 Docker Daemon 的 具体 实 
现 ， 可 以 对 Docker 架 构 有 一 个 较为 全 面 的 认识 。 总 结 而 言 ，Docker 
的 运行 载体 为 Daemon , 调度 管理 由 Engine 负 责 ， 任 务 执行 靠 Job。 


第 4 章 Docker Daemon 之 NewDaemon 实 现 
4.1 引言 


Docker 的 生态 系统 日 趋 完善 ， 开 发 者 群体 也 在 日 趋 庞大 ， 这 些 现 
象 都 使 得 工业 界 对 Docker 持 续 抱 有 乐观 的 态度 。 如 今 ， 对 于 广大 开发 
者 而 言 ， 使 用 Docke 中 然 不 是 门槛 ,享受 Docker 带 来 的 福利 也 不 再 
困难 。 然 而 ， 如 何 探寻 Docker 适 应 的 场景 ， 如 何 发 展 Docker 周 边 的 
技术 ， 以 及 如 何 弥 合 Docker 新 技术 与 传统 物理 机 或 虚拟 机 技术 之 间 的 
鸿沟 ,已 经 成 为 Docker 研 究 者 们 要 思考 与 解决 的 问题 。 


在 Docker 架 构 中 Docker Daemon 支 撑 着 整个 后 台 进 程 的 运 
行 ， 同 时 也 统一 化 管理 着 Docker 架 构 中 graph、graphdriver.、 
execdriver、Vvolumes、Docke 容 问 等 众多 资源 。 可 以 说 ，Docker 
Daemon 复 杂 的 运作 均 由 daemon 对 象 来 调度 , 而 NewDaemon 的 
实现 恰巧 可 以 帮助 大 家 了 解 这 一 切 的 来 龙 去 脉 。 通 过 本 章 内 容 的 介 
绍 ,我 们 力求 帮助 广大 Docker 爱 好 者 更 多 地 理解 Docker 的 核心 一 一 
Docker Daemon 的 实现 。 


本 章 从 源码 角度 ,分析 Docker Daemon 加 载 过 程 中 
NewDaemon 的 实现 ， 整个 分 析 过 程 如 图 4-1 所 示 。 


由 图 4-1 可 见 ，Docker Daemon 中 NewDaemon 的 执行 流程 主 
要 包含 12 个 独立 的 步骤 : 处 理 配 置信 息 、 检 测 系统 支持 及 用 户 权限 、 
配置 工作 路 径 、 加 载 并 配置 graphdriver、 创 建 Docker Daemon 网 
络 环境 、 创 建 并 初始 化 graphdb、 创 建 execdriver、 创 建 daemon 
实例 、 检 测 DNS 配 置 、 加 载 已 有 容 久 、 设 置 shutdown 处 理 方法 ， 以 
及 返回 daemon 实 例 。 


下 面 我 们 将 在 NewDaemon 的 具体 实现 中 ， 详 细 分 析 以 上 内 容 。 












处 理 进程 PID 文件 
设备 


启用 iptables 功能 


启用 系统 数据 转发 
功能 


图 4-1 Docker Daemon 中 NewDaemon 执 行 流程 图 


4.2 NewDaemon 具 体 实 现 


本 书 第 3 章 对 于 Docker Daemon 局 动 的 分 析 过 程 ， 有 这 样 一 个 
环节 : 使 用 协 程 加 载 daemon 对 象 。 在 加 载 并 运行 daemon 对 和 象 时 ， 
所 做 的 第 一 个 工作 是 : 


d, err := daemon.NewDaemon(daemonCfg, eng) 
简单 分 析 一 下 这 行 代 码 。 
级 数 名 : NewDaemon 


调用 此 六 数 的 包 名 : daemon 


级 数 具体 实现 源 文件 : ./dockerdockerdaemon/daemon.go 
级 数 传 入 实 参 : daemonCfg , 定义 Docker Daemon 运 行 过 程 中 所 
需 的 众多 配置 信息 ; eng, 在 mainDaemon 中 创建 的 Engine 对 象 实 
例 


: 哎 数 返回 内 容 : d, 具体 的 Daemon 对 象 实例 ; err , 错误 状态 


进入 ./docker/docker/daemon/daemon.go 中 ,寻找 负数 
NewDaemon 的 具体 实现 ， 源码 如 下 : 


func NewDaemon(config *Config, eng *engine.Engine) (*Daemon, error) { 
daemon, err := NewDaemonFromDirectory(config, eng) 
if err != nil { 
return nil, err 


return daemon, nil 


可 见 ， 在 实现 NewDaemon 的 过 程 中 ,要 通过 
NewDaemonFromDirectory 孙 数 来 实现 创建 Daemon 的 运行 环 
境 。 该 函数 的 实现 ， 传 入 参数 以 及 返回 类 型 与 NewDaemon 也 数 完全 
相同 。 接 下 来 将 详细 分 析 NewDaemonFromDirectory 的 实现 细节 。 


4.3 ”应 用 配置 信息 


NewDaemonFromDirectory 的 实现 过 程 中 ， 第 一 个 工作 是 : 如 
何 应 用 传 入 的 配置 信息 。 这 部 分 配置 信息 服务 于 Docker Daemon 的 
运行 ， 并 在 Docker Daemon 月 动 初 期 初始 化 完毕 。 配 置信 息 的 主要 
功能 是 : 供用 户 自由 配置 Docker 的 可 选 功能 ， 使 得 Docker 的 运行 更 
占 近 用 户 期 待 的 运行 场景 。 


> 三 


配置 信息 的 处 理 包含 4 部 分 : 
配置 Docker 容 器 的 MTU 
检测 网 桥 配置 信息 
:查验 容 屁 间 的 通信 配置 
:处理 PID 文 件 配置 


下 面 乏 一 分 析 配 站 信息 的 处 理 。 


4.3.1 配置 Docker 容 器 的 MTU 


config 信 息 中 的 Mtu 属 性 应 用 于 容 希 网 络 接口 的 最 大 传输 单元 
( MTU) 特性 。 有 关 MTU 的 源码 如 下 : 


if config.Mtu == 0 { 
config.Mtu = GetDefaultNetworkMtu() 
} 


可 见 ， 若 config 信 息 中 Mtu 的 值 为 0，Docker 则 通过 
GetDefaultNetworkMtu 函 数 将 Mtu 设 定 为 默认 的 值 ; 否则 , 采用 
config 中 的 Mtu 值 。 由 于 在 默认 的 配置 文 
件 ./docker/docker/daemon/config.go( 下 文 简称 为 默认 配置 文 
件 ) 中 ，Mtu 属 性 的 初始 值 为 0 , 故 执行 GetDefaultNetworkMtu。 


GetDefaultNetworkMtu 纯 数 的 具体 实现 位 
于 ./docker/daemon/config.go#L65-L70 , 如下: 


func GetDefaultNetworkMtu() int { 
if iface, err := networkdriver.GetDefaultRouteIface(); err == nil { 
return iface.MTU 


} 
return defaultNetworkMtu 


在 GetDefaultNetworkMtu 的 实现 中 ，Docker 通 过 
networkdriver 包 的 GetDefaultRoutelface 方 法 获取 具体 的 网 络 接 


口 ， 若 该 网 络 接口 存在 ， 则 返回 该 网 络 接口 的 MTU 属 性 值 ; 否则 返回 
上 默认 的 MTU 值 defaultNetworkMtu , 值 为 1500。 


4.3.2 ” 检 市 网 桥 配 直 信 息 


处 理 完 config 中 的 Mtu 属 性 之 后 , Docker 马 上 检测 config 信 息 中 
Bridgelface 和 BridgelP 这 两 个 属性 。Bridgelface 和 BridgelP 的 作 
用 是 为 创建 网 桥 的 任务 init_networkdriver 提 供 参 数 ， 源 码 如 下 : 


if config.BridgeIface != "" &é& config,BridgeIP != "" { 

return nil, fmt.Errorf("You specified -b & --bip, mutually exclusive 
options. Please specify only one.") 
} 


以 上 代码 的 含义 为 : 若 config 中 Bridgelface 和 BridgelP 两 个 属 
性 均 不 为 空 ， 则 返回 Nil 对象， 并 返回 错误 信息 ,错误 信息 内 容 为 : 用 
户 同 时 指定 了 Bridgelface 和 BridgelP , 这 两 个 属性 属于 互 斥 类 型 ， 
只 能 指定 其 中 之 一 。 原 因 是 : 当 用 户 为 Docker 网 桥 选 定 已 经 存在 的 网 
桥接 口 时， 应 该 沿用 已 有 网 桥 的 当前 IP 地 址 ， 不 应 绸 提供 IP 地 址 ; 当 
用 户 不 选 已 经 存在 的 网 桥接 口 作为 Docker 网 桥 时 ，Docker 会 另行 创 
建 一 个 全 新 的 网 桥接 口 作为 Docker 网 桥 ， 此 时 用 户 可 以 为 此 新 创建 的 
网 桥接 口 设 定 自 定义 IP 地 址 ; 当然 两 者 都 不 选 的 话 ，Docker 会 为 用 户 
接管 完整 的 Docker 网 桥 创建 流程 ， 从 创建 默认 的 网 桥接 口 ， 到 尾 网 桥 
接口 设置 默认 的 IP 地 址 。 而 在 默认 配置 文件 中 ， Bridgelface 和 
BridgelP 的 值 均 为 空 字 符 串 。 


4.3.3 查验 容 冀 间 的 通信 配置 


查验 容 希 间 的 通信 配置 ， 主 要 是 针对 config 信 息 中 的 


Enablelptables 和 InterContainer Communication 属性 。 


Enablelptables 属 性 主要 来 源 于 flag 参 数 --iptables， 它 的 作用 
是 : 在 DockerDaemon 启 动 时 ,是 否 对 宿主 机 的 iptables 规 则 作 修 
改 。 若 Enablelptables 的 值 为 false， 则 代表 Docker Daemon 有 启动 
时 不 对 宿主 机 的 iptables 规 则 作 任 何 修 改 ; 若 Enablelptables 的 值 为 
true ， 则 代表 Docker Daemon 启动 时 对 宿主 机 的 iptables 规 则 作 修 
改 。 


仅仅 分 析 Enablelptables 的 作用 ， 显 得 有 些 抽象 ， 理 解 起 来 也 较 
为 生 深 。 结 合 InterContainerCommunication 来 分 析 ， 就 会 变 得 自 
然 很 多 。InterContainerCommunication 属 性 来 源 于 flag 参 数 -- 
icc , 它 的 作用 是 : 在 Docker Daemon 启 动 时 ， 是 否 开启 Docker 容 
器 之 间 互 相通 信和 的 功能 。 若 InterContainerCommunication 的 值 为 
false, 则 Docker Daemon 会 在 答 主 机 iptables 的 FORWARD 链 中 添 
加 一 条 Docker 容 莫 间 流量 均 DROP 的 规则 ; 若 


InterContainerCommunication 为 true , 则 Docker Daemon 会 在 


宿主 机 iptables 的 FORWARD 链 中 添加 一 条 Docker 容 器 间 流 量 均 
ACCEPT 的 规则 。 


通过 分 析 以 上 的 内 容 ， 我 们 可 以 发 现 : 
InterContainerCommunication 的 值 不 论 为 false 还 是 为 true ,都 
会 在 Docker Daemon 启 动 时 ，, 动用 iptables , 故 Enablelptables 的 
值 只 能 为 true ,必须 允许 Docker Daemon 启 动 时 对 iptables 规 则 作 
修改 的 操作 。 男 外 ， 若 Enablelptables 为 true ， 则 说 明 Docker 
Daemon 启 动 时 允许 对 iptables 规 则 作 修 改 ， 而 此 时 若 
InterContainerCommunication 为 false， 则 说 明 Docker Daemon 
添加 一 条 DROP 的 规则 ,导致 Docker 容 器 间 不 能 互相 通信 ，, 在 此 情况 
下 ，Docker 提 供 容 莫 间 link 的 机 制 ， 仍然 可 以 帮助 容 莫 实现 互相 通 


信 。 
查验 容 右 间 通 信和 配置 的 源码 如 下 : 


if !config.EnableIptables &é& !config,InterContainerCommunication { 

return nil, fmt.Errorf("You specified --iptables=false with -- 
icc=false. ICC uses iptables to function. Please set --icc or --iptables to 
true.") 


代码 含义 为 : 若 Enablelptables 和 
InterContainerCommunication 两 个 属性 的 值 均 为 false ,， 则 返回 
nil 对 象 以 及 错误 信息 。 其 中 错误 信息 为 : 用 户 将 以 上 两 属性 均 置 为 


false， 容 问 间 通信 需要 iptables 的 支持 ， 需 设置 其 中 之 一 为 true。 而 
在 默认 配置 文件 中 ,这 两 个 属性 的 值 均 为 true。 


4.3.4 处 理 网 络 功能 配置 


接着 ，Docker 处 理 config 中 的 DisableNetwork 属 性 ， 后 续 创 建 
并 执行 创建 Docker Daemon 网 络 环境 时 会 使 用 此 属性 ， 即 在 名 为 
init_ networkdriver 的 job 创建 并 运行 中 体现 。 


config.DisableNetwork = config.BridgeIface == DisableNetworkBridge 


由 于 config 信 息 中 的 Bridgelface 属 性 值 为 空 ， 另 外 
DisableNetworkBridge 的 值 为 字符 串 none ,因此 最 终 config 中 
DisableNetwork 的 值 为 false。 后 续 名 为 init_networkdriver 的 Job 
执行 时 ， 需 要 使 用 DisableNetwork 这 个 属性 。 


4.3.5 ”处 理 PID 文 件 配 置 


处 理 PID 文 件 配置 ， 主 要 工作 是 : 为 运行 时 Docker Daemon 进 
程 的 PID 号 创建 一 个 PID 文 件 ,文件 的 路 径 即 为 config 中 的 Pidfile 属 
性 ， 并 且 为 Docker Daemon 的 shutdown 操 作 添加 一 个 删除 此 
Pidfile 的 函数 ， 以 便 在 Docker Daemon 退 出 的 时 候 ， 可 以 在 第 一 时 
间 册 除 Pidfile。 实 现 处 理 PID 文 件 配置 信息 的 源码 如 下 : 


if config.Pidfile != "" { 
if err := utils.CreatePidFile(config.Pidfile); err != nil { 
return nil, err 


eng.OnShutdown(func() { 
utils.RemovePidFile(config.Pidfile) 


在 代码 执行 过 程 中 ， 首 先 检测 config 中 的 Pidfile 属 性 是 否 为 空 ， 
若 为 空 ， 则 跳 过 代码 块 继续 执行 ; 若 不 为 空 ， 则 首先 在 文件 系统 中 创 
建 具体 的 Pidfile， 然后 向 eng 的 onShutdown 属 性 添加 一 个 处 理 函 
数 , 国 数 具 体 完成 的 工作 为 utils.RemovePidFile 
( config.Pidfile) , 即 在 Docker Daemon 进行 shutdown 操 作 的 时 
候 ， 删 除 Pidfile 文 件 。 在 默认 配置 文件 中 ，Pidfile 文 件 的 初始 值 
为 "/varrun/dockerpid "。 


以 上 便 是 关于 NewDaemon 实 现 过 程 中 配置 信息 的 处 理 分 析 。 


4.4 检测 系统 文 持 及 用 户 权限 


初步 处 理 完 Docker 的 配置 信息 之 后 ,Docker 立 即 对 自身 的 运行 
环境 进行 一 系列 的 检测 。 检 测 主要 包括 以 下 三 方面 : 


:操作 系统 类 型 对 Docker Daemon 的 支持 ; 
用户 权 限 的 级 别 ; 

-内核 版 本 与 处 理 器 的 支持 。 

系统 支持 与 用 户 权 限 检测 的 实现 较为 简单 ， 源 码 实 现 如 下 : 


if runtime.G00S != "linux" { 
log.Fatalf("The Docker daemon is only supported on linux") 


} 
if os.Geteuid() != 0 { 
log.Fatalf("The Docker daemon needs to be run as root") 


if err := checkKernelAndArch(); err != nil { 
log.Fatalf (err.Error()) 


首先 ,通过 runtime.GOOS 检 测 操作 系统 的 类 型 。 
runtime.GOOS 返 回 运 行程 序 所 在 操作 系统 的 类 型 ， 可 以 是 LinuxX、 
Darwin、FreeBSD 等 。 结 合 具体 代码 ， 可 以 发 现 ， 知 操作 系统 不 为 
Linux , 将 报 出 Fatal 错 误 日 志 ，, 内容 为 "Docker Daemon 只 能 支持 
Linux 操 作 系 统 ”。 


接着 ， 通 过 os.Geteuid( ) ， 检测 程序 用 户 是 否 拥有 足够 权限 。 
os.Geteuid( ) 返回 调用 者 所 在 组 的 组 id。 结 合 具 体 源码 分 析 可 知 ， 
若 返回 不 为 0， 则 说 明 docker 程 序 不 是 以 root 用 户 的 身份 运行 ， 报 出 


Fatal 错 误 日 志 。 


最 后 ,通过 checkKernelAndArch( ) ,检测 内 核 的 版 本 以 及 主 
机 处 理 器 类 型 。checkKernel-AndArch( ) 的 实现 同样 位 
于 ./docker/docker/daemon/daemon.go#L1097-L1119。 实 现 过 
程 中 ， 第 一 个 工作 是 : 检测 程序 运行 所 在 的 处 理 希 架构 是 人 否 
为 “amd64”, 而 目前 Docker 运 行 时 只 能 文 持 amd64 的 处 理 莫 架构 。 
第 二 个 工作 是 : 检测 Linux 内 核 版 本 是 含 满 足 要 求 ， 而 目前 Docker 
Daemon 运 行 所 需 的 内 核 版 本 若 过 低 ， 则 很 有 可 能 出 现 不 稳定 的 状 
况 ， 因 此 Docker 官 方 建议 用 户 升级 内 核 版 本 至 3.8.0 或 以 上 版 本 ( 包 
括 3.8.0) 。 


4.5 配置 工作 路 径 


配置 Docker Daemon 的 工作 路 径 ， 主 要 是 创建 Docker 
Daemon 运 行 中 所 在 的 工作 目录 。 实 现 过 程 中 ， 通 过 config 中 的 
Root 属性 来 完成 。Docker Daemon 的 root 组 录 作 用 非常 大 ， 几 乎 涵 
萝 Docker 在 宿主 机 上 运行 的 所 有 信息 , 包括 : 所 有 的 Docker 镜 像 内 
容 、 所 有 Docker 容 右 的 文件 系统 、 所 有 Docker 容 妖 的 元 数据 、 所 有 
容 莫 的 数据 卷 内 容 等 。 


在 默认 配置 文件 中 ，Root 属 性 的 值 为"/varlib/docker ”。 
在 配置 工作 路 径 的 代码 实现 中 ,步骤 如 下 : 

1) 使 用 规范 路 径 创 建 一 个 TempDir , 路径 名 为 tmp。 

2) 通过 tmp , 创建 一 个 指向 tmp 的 文件 符号 连接 realTmp。 
3) 使 用 realTemp 的 值 ，, 创建 并 赋值 给 环境 变量 TMPDIR.。 
4) 处 理 config 的 属性 EnableSelinuxSupport。 


5) 将 realRoot 重 新 赋值 于 config.Root , 并 创建 Docker 
Daemon 的 工作 根 目录 。 


4.6 加 载 并 配置 graphdriver 


加 载 并 配置 存储 驱动 graphdriver ,目的 在 于 : 使 得 Docker 
Daemon 创 建 Docker 镜 像 管理 所 需 的 驱动 环境 。graphdriver 用 于 
完成 Docker 镜 像 的 管理 ， 包括 获 取 、 存 储 以 及 容 希 rootfs 的 构建 等 。 


4.6.1 创建 graphdriver 


创建 graphdriver 的 内 容 源码 位 
于 ./docker/docker/daemon/daemon.go#L743-L790。 具 体 细 节 
分 析 如 下 : 


graphdriver.DefaultDriver = config.GraphDriver 
driver, err := graphdriver.New(config.Root, config.GraphOptions) 


首先 ,Docker 对 graphdriver 包 中 的 DefaultDriver 对 象 赋值 ， 
值 为 Config 中 的 GraphDriver 属 性 ， 在 默认 配置 文件 中 ， 
GraphDriver 属 性 的 值 为 空 ; 同样 的 ， 属 性 GraphOptions 也 为 空 。 
然后 通过 GraphDriver 中 的 new 哨 数 实现 加 载 graph 的 存储 驱动 。 


创建 具体 的 graphdriver 是 极其 重要 的 一 个 环节 ,实现 细节 由 
graphdriver 包 中 的 New 蚊 数 来 完成 。New 明 数 的 实现 位 
于 ./docker/docker/daemon/graphdriver/driver.go#1L81- 
L111， 实现 步 又 如 下 : 


第 一 ,遍历 数组 选择 graphdriver ,数组 内 容 为 os.Getenv 
("DOCKER _DRIVER") 和 DefaultDriver。 若 数组 不 为 空 ， 
graphdriver 则 通过 GetDriver 纹 数 直接 返回 相应 的 Driver 对 象 实 
例 ; 若 为 空 ， 则 继续 往 下 执行 。 这 部 分 内 容 的 作用 是 : 让 


graphdriver 的 加 载 首 先 满足 用 户 的 自 定义 选择 ， 用 户 可 以 通过 定义 
环境 变量 的 方式 定义 9raphdriver 的 类 型 ， 其 次 Docker 采 用 默认 值 ， 
源码 如 下 : 


for , name := range []string{os.Getenv("DOCKER DRIVER"), DefaultDriver} { 
if name != "" { 


return GetDriver(name, root, options) 
} 
} 


AA 一 


第 二 ,遍历 优先 级 数组 priority 选 择 graphdriver ,优先 级 数组 
priority 的 内 容 依 次 为 aufs、btrfs、devicemapper 和 vfs。 若 遍历 
验证 时 ，GetDriver 成 功 ， 则 直接 返回 当前 的 Driver 对 象 实例 ; 若 不 
成 功 ， 则 继续 往 下 执行 。 这 部 分 内 容 的 作用 是 : 在 没有 指定 以 及 默认 
的 驱动 时 ， 从 优先 级 数组 中 选择 驱动 ， 目 前 优先 级 最 高 的 为 aufs， 源 
码 如 下 : 

ee 


if err != nil 
if err == ErrNotSupported || err == ErrPrerequisites || err == 
ErrIncompatibLeFS { 
continue 
return nil, err 


return driver, nil 


第 三 ， 从 已 经 注册 的 drivers 数 组 中 选择 graphdriver ,源码 如 


for , initFunc := range drivers { 


if driver, err = initFunc(root, options); err != nil { 
if err == ErrNotSupported || err == ErrPrerequisites || err == 
ErrIncompatibLeFS { 
continue 


return nil, err 
} 和 
return driver, nil 


return nil, fmt.Errorf("No supported storage backend found") 


在 aufs、btrfs、devicemapper 和 vfs 四 个 不 同类 型 驱动 的 init 
函数 中 ,它们 均 向 graphdriver 的 drivers 数 组 注册 了 相应 的 初始 化 方 
法 。 分 别 位 
于 ./docker/docker/daemon/graphdriver/aufs/aufs.go ,以 及 其 
他 三 类 驱动 的 相应 位 置 。 这 部 分 内 容 的 作用 是 : 在 没有 优先 级 数组 的 
时 候 ， 同样 可 以 通过 注册 的 驱动 来 选择 具体 的 graphdriver。 


4.6.2 ”验证 btrfs 与 SELinux 的 兼容 性 


由 于 目 前 在 btrfs 文 件 系统 上 运行 的 Docker 不 兼容 SELinux ， 
此 当 config 中 配置 信息 需要 启用 SELinux 的 支持 并 且 驱 动 的 类 型 为 
btrfs 时 ,返回 nil 对象， 并 报 出 Fata 旧 志 。 代 码 实现 如 下 : 


// As Docker on btrfs and SELinux are incompatible at present，error on both 
being enabled 


if config.EnableSelinuxSupport && driver.String() == "btrfs" { 


return nil, fmt.Errorf("SELinux is not supported with the BTRFS graph 
driver!") 


4.6.3 ”创建 容器 仓库 目录 


Docker Daemon 在 创建 Docker 容 器 之 后 ， 需 要 将 容器 的 元 数 
据 信息 放置 于 某 个 仓库 目录 下 ， 统 一 管理 。 而 这 个 目录 即 为 
daemonRepo , 值 为 : "/var/lib/docker/containers"。Docker 通 
过 daemonRepo 创 建 对 应 的 目录 。 源 码 实现 如 下 : 


daemonRepo := path.Join(config.Root, "containers") if err := 
os.MkdirAll (daemonRepo, 0700); err != nil SA& !os.IsExist(err) { 


return nil, err } 


4.6.4 迁 移 容 堪 至 aufs 类 型 


Docker Daemon 的 启动 很 有 可 能 不 是 第 一 次 ， 因 此 Docker 环 
境 中 也 有 可 能 存在 一 部 分 的 遗留 内 容 ; Docker Daemon 也 有 可 能 是 
版 本 升级 后 的 第 一 次 局 动 , Docker 环 境 中 同样 有 可 能 存在 遗留 内容。 
因此 , 当 graphdriver 的 类 型 为 aufs 时 , DockerDaemon 局 动 需要 
将 现 有 容器 roo 组 录 下 的 相应 内 容 都 迁移 至 aufs 类 型 ; 若 不 为 aufs ， 
则 继续 往 下 执行 。 


对 于 aufs 类 型 的 graphdriver , 在 Docker 0.7 .x 版 本 之 前 ， 
Docker 将 容 右 镜像 的 镜像 层 内 容 以 及 镜像 元 数据 均 放 在 同一 个 目录 
下 ， 迁移 操作 要 完成 将 以 上 两 者 拆 分 存储 ， 以 满足 新 版 Docker 的 
aufs 支 持 。 关 于 Docker 镜 像 的 存储 ,可 参见 第 10 章 。 


实现 源码 如 下 : 


if err = migrateIfAufs(driver, config.Root); err != nil { 
return nil, err 
} 


这 部 分 的 迁移 内 容 主要 包括 Repositories、Images 以 及 
Containers , 具体 源码 实现 位 


于 ./docker/docker/daemon/graphdriver/aufs/migrate.go#L39 
-L50 ,如 下 所 示 : 


func (a *Driver) Migrate(pth string, setupInit func(p string) error) error { 
if pathExists(path.Join(pth, "graph")) { 


if err := a.migrateRepositories(pth); err != nil { 
return err 
} 
if err := a.migrateImages(path.Join(pth, "graph")); err != nil { 
return err 
return a.migrateContainers(path.Join(pth, "containers"), setupInit) 
return nil 


迁移 镜像 库 的 功能 是 : 在 Docker Daemon 的 root 工 作 目 录 下 创 
建 repositories-aufs 的 文件 ， 存储 所 有 与 镜像 相关 的 镜像 库 以 及 镜像 
标签 信息 。 


迁移 Docker 镜 像 的 主要 功能 是 : 将 原 有 的 image 镜 像 都 了 迁移 至 
aufs 邓 动能 识别 并 使 用 的 类 型 ， 主 要 是 拆 分 镜像 原先 的 存储 方式 ， 将 
内 容 了 迁移 到 aufs 所 规定 的 layers、diff 与 mn 组 录 。 


迁移 容 怖 的 主要 功能 是 : 将 Docker 原 先 的 容器 运行 环境 使 用 
aufs 驱 动 来 进行 迁移 配置 ， 包括 创建 容器 的 rootfs ,配置 容器 初始 层 
(init layer) ,创建 容器 的 读 写 层 等 。 


4.6.5 ”创建 镜像 graph 


创建 镜像 graph 的 主要 工作 是 : 通过 Docker 的 roo 组 录 以 及 
graphdriver 实 例 ， 实例 化 一 个 全 新 的 graph 对 象 ， 用 以 管理 在 文件 
系统 中 Docker 的 root 路 径 下 graph 目 录 的 内 容 。graph 目 录 下 的 文件 
以 镜像 ID 为 单位 ， 分 别 存储 单个 镜像 的 json 文 件 以 及 镜像 的 大 小 文件 
layersize。 其 中 镜像 的 json 文 件 包含 镜像 自身 的 元 数据 信息 。 实 现 源 
码 如 下 : 


g, err := graph.NewGraph(path.Join(config.Root, "graph"), driver) 


NewGraph 的 具体 实现 位 
于 ./docker/docker/graph/graph.go， 实现 过 程 中 返回 的 对 象 为 
Graph 类 型 ， 定 义 如 下 : 


type struct { 
string 
i *truncindex.TruncIndex 
driver graphdriver.Driver 


} 


其 中 Root 表示 graph 的 工作 根 目录 ， 一般 
为 "/var/lib/docker/graph" ; idlndex 使 得 检索 字符 串 标 识 符 时 ， 人 允 
许 使 用 任意 一 个 该 字符 串 唯 一 的 前 缀 ， 只 要 该 前 缀 全 局 唯一 ， 则 可 确 


保 找到 相应 的 镜像 。 在 这 里 ，idlndex 用 于 通过 简短 有 效 的 字符 串 前 
缀 检索 镜像 的 ID ; 最 后 driver 表 示 具 体 的 graphdriver 类 型 。 


4.6.6 创建 volumesdriver 以 及 volumes 
graph 


在 Docker 中 数据 卷 ( volume) 的 概念 是 : 可 以 从 Docker 信 主 
机 上 挂 载 到 Docker 容 右 内 部 的 特定 目录 。 一 个 数据 卷 可 以 被 多 个 
Docker 容 器 挂 载 ， 从 而 使 Docker 容 器 可 以 实现 互相 共享 数据 等 。 在 
实现 数据 卷 时 ，Docker 需 要 使 用 driver 来 管理 已 ， 又 由 于 数据 卷 的 管 
理 不 会 像 容 器 文件 系统 管理 那么 复杂 , 故 Docker 染 用 vfs 驱 动 实现 数 
据 卷 的 管理 。 


Docker 的 范畴 中 ， 数 据 卷 可 以 分 为 两 种 : 第 一 种 ， 用户 使 用 
docker run 命 令 启 动容 颖 时 传 入 -v A : B ,使 得 宿主 机 上 的 目录 人 A 可 
以 挂 载 到 容 希 内 部 的 目录 B ，; 第 二 种 ， 用 户 在 使 用 Dockerfile 时 使 
用 命令 VOLUME/data , 或 者 使 用 dockerrun 命 令 启动 容器 时 传 入 - 
v/data ， 用 户 虽然 指定 在 宿主 机 上 的 目录 ， 但 是 Docker Daemon 一 
般 情 况 下 会 接管 稍 主 机 上 的 目录 创建 ， 并 绸 将 目录 挂 载 至 Docker 容 着 
内 部 ， 此 时 宿主 机 上 的 目录 一 般 位 
于 "/var/lib/docker/vfs/dir/<1D>"。 第 一 种 数据 卷 通常 可 以 将 其 称 
为 bind-mount volume , 而 第 二 种 通常 称 为 data volume。 


于 volumes graph 上 创建 volumesdriver 的 源码 实现 如 下 : 


volumesDriver, err := graphdriver.GetDriver("vfs", config.Root, 
config.GraphOptions) 
volumes, err := graph.NewGraph(path.Join(config.Root, "volumes"), volumesDriver) 


主要 完成 工作 为 : 使 用 vfs 这 种 类 型 的 driver 创 建 
volumesDriver ; 在 Docker 的 root 略 径 下 创建 volumes 目 录 ,并 返 


回 volumes 这 个 graph 对 象 实例 。 


4.6.7 ”创建 TagStore 


TagStore 主 要 是 用 于 管理 存储 镜像 的 仓库 列表 ( repository 
list) 。 


创建 tagStore 的 源码 如 下 : 


repositories, err := graph.NewTagStore(path.Join(config.Root, "repositories- 
"+driver.String()), 9g) 


级 数 NewTagStore 的 实现 位 
于 ./docker/docker/graph/tags.go ，TagStore 的 定义 如 下 : 


type TagStore struct { 
path 


string 
graph *Graph 
Repositories map[string]Repository 
sync.Mutex 


pullingPool map[string]chan struct{} 
pushingPool map[string]chan struct{} 


需要 阐述 的 是 TagStore 类 型 中 的 多 个 属性 的 含义 。 


path : TagStore 中 记录 镜像 仓库 的 文件 所 在 路 径 ， 如 aufs 类 型 
的 TagStore path 的 值 为 "/var/lib/docker/repositories-aufs"。 


graph : 相应 的 Graph 实例 对 象 。 


:Repositories : 记录 镜像 仓库 的 映射 数据 结构 。 
:Sync.Mutex : TagStore 的 互 斥 锁 。 


“pullingPool : 记录 池 ， 记 录 有 哪些 镜像 正在 被 下 载 ， 和 看 肝 一 个 
镜像 正在 被 下 载 ， 则 驳回 其 他 Docker Client 发 起 下 载 该 镜像 的 请 
求 。 


:pushingPool : 记录 池 ，, 记录 有 哪些 镜像 正在 被 上 传 ， 若 某 一 个 
镜像 正在 被 上 传 ， 则 驶 回 其 他 Docker Client 发 起 上 传 该 镜像 的 请 
求 。 


4.7 ”配置 Docker Daemon 网 络 环境 


创建 Docker Daemon 运行 环境 的 时 候 ， 配置 Docker 所 在 宿主 
机 的 网 络 环境 是 极为 重要 的 一 个 环节 。 这 不 仅 关 系 着 将 来 容 左 对 外 的 
通信 ，, 同样 也 关系 着 容器 间 的 通信 。 


配置 Docker 宿 主机 的 网 络 环境 时 ,Docker Daemon 通 过 运行 
名 为 init_networkdriver 的 Job 来 完成 。 源 码 实现 如 下 : 


if !config.DisableNetwork { 
job := eng.Job("init networkdriver") 
job.SetenvBool ("EnableIlptables", config.EnableIptables) 
job.SetenvBool("InterContainerCommunication", 
config.InterContainerCommunication) 
job.SetenvBool ("EnableIpForward", config.EnableIpForward) 
job.Setenv("BridgeIlface", config.Bridgelface) 
job.Setenv("BridgeIP", config.BridgeIP) 
job.Setenv("DefaultBindingIP", config.DefaultIp.String()) 
if err := job.Run(); err != nil { 
return nil, err 
} 


} 


分 析 以 上 源码 可 知 ， 通过 config 中 的 DisableNetwork 属 性 来 判 
断 是 人 否 执行 job。 在 默认 配置 文件 中 ， 该 属性 兽 被 定义 ， 却 没有 初始 
值 ， 然 而 在 应 用 配置 信息 这 个 步 又 ( 4.3 节 ) ，Docker 处 理 网 络 功能 
配置 时 , 将 DisableNetwork 属 性 赋值 为 false。 故 以 上 判断 语句 结果 
为 true， 执行 相应 的 代码 块 。 


配置 DockerDaemon 网 络 环境 的 工作 主要 通过 
init_ networkdriver 这 个 job 来 完成 。Docker 首 先 创建 名 为 
init_networkdriver 的 Job ,随后 为 此 job 设 置 环境 变量 ， 环境 变量 的 
值 如 下 : 


:环境 变量 Enablelptables , 使 用 config.Enablelptables 来 赋 
值 , 默认 值 为 true。 


.环境 变量 InterContainerCommunication ,使 用 


config.InterContainerCommunication 来 赋值 ， 为 默认 值 true。 


:环境 变量 EnablelpForward , 使 用 config.EnablelpForward 来 
赋值 ,默认 值 为 true。 


:环境 变量 Bridgelface , 使 用 config.Bridgelface 来 赋值 ， 为 空 
字符 串 ""。 

.环境 变量 BridgelP ,使 用 config.BridgelP 来 赋值 ， 为 空 字符 
捉 ou 


:环境 变量 DefaultBindinglP，, 使 用 config.Defaultlp.String 
( ) 来 赋值 ， 默认 值 为 "0.0.0.0"。 


设置 完 环境 变量 之 后 ，Docker 随 即 运行 此 job , 由 于 在 eng 中 


key 为 init_networkdriver 的 handler , value 为 bridge.InitDriver 


孙 数 ， 故 执行 bridge.InitDriver 员 数 ， 具 体 的 实现 位 
于 ./docker/docker/daemon/networkdriver/bridge/dirver.go ， 


作用 为 : 
:获取 为 Docker 容 怖 服务 的 网 络 接口 IP 地 址 。 
-创建 指定 1P 地 址 的 网 桥接 口 。 
“启用 lptables 功 能 并 进行 配置 。 


:另外 ， job 为 eng 实 例 注册 了 4 个 Handler , Handler 名 分 别 为 : 


allocate interface、release interface、allocate_port 和 link。 


Docker Daemon 的 网 络 初 始 化 关 平 Docker 容 问 的 通信 和 能力 ， 
是 Docker 架 构 中 最 为 基础 的 知识 之 一 。 第 6 章 将 为 大 家 分 析 Docker 
Daemon 网 络 环境 的 创建 。 


4.7.1 创建 Docker 网 络 设备 


创建 Docker 网 络 设 备 ， 属 于 Docker Daemon 创建 网 络 环境 的 
第 一 步 ， 实 际 工作 是 创建 名 为 docker0 的 网 桥 设 备 。 


在 InitDriver 柱 数 运行 过 程 中 ，Docker 首 先 使 用 job 的 环境 变量 
初始 化 内 部 变量 ; 然后 根据 目 前 网 络 环境 , 判断 是 否 创建 docker0 网 
桥 ， 若 Docker 专 属 网 桥 已 存在 ， 则 继续 往 下 执行 ; 否则 ,创建 
docker0 网 桥 。 具 体 实现 为 createBridge( bridgelP) ， 以 及 


createBridgelface( bridgelface) 。 


createBridge 的 功能 是 : 在 宿主 机 上 启动 创建 指定 名 称 网 桥 设备 
的 任务 ， 并 为 该 网 桥 设备 配置 一 个 与 其 他 设备 不 冲突 的 网 络 地址 。 而 
createBridgelface 通 过 系统 调用 负责 创建 具体 实际 的 网 桥 设备 ， 并 
设置 MAC 地 址 ,通过 libcontainer 中 netlink 包 的 CreateBridge 来 实 
现 ， 


4.7.2 启用 iptables 功 能 


Fe 口 口 


创建 完 网 桥 之 后 ，Docker Daemon 为 未 来 的 Docker 容 器 以 及 
宿主 机 配置 jptables 规 则 ,作用 是 : 为 Docker 容 希 之 间 的 link 操 作 提 
供 iptables 防 火 墙 支持 。 源 码 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver/driver 


.go#L133-L137 ,如 下 所 示 : 


// Configure iptables for link support 
if enableIPTables { 
if err := setupIPTables(addr, icc); err != nil { 
return job.Error(err) 


其 中 setuplPtables 的 调用 过 程 中 ，addr 地 址 为 Docker 网 桥 的 
网 络 地 址 ，icc 为 true , 即 允 许 Docker 容 器 间 互 相 访问 。 假 设 网 桥 设 
备 名 为 docker0， 网 桥 网 络 地 址 为 docker0_ip， 设 置 ijptables 规 则 ， 
具体 操作 步 又 如 下 : 


1) 使 用 iptables 工 具 开 启 新 建 网 桥 的 NAT 功 能 ， 使 用 如 下 命 


令 : 


iptables -I POSTROUTING -t nat -s docker0 ip ! -0o docker0 -j MASQUERADE 


2) 通过 icc 参 数 ， 决定 是 否 允 许 Docker 容 器 间 的 通信 ， 并 制定 相 
应 iptables 的 Forward 链 。Docker 容 器 之 间 建 立 通信 ,说明 数 据 包 从 
源 容 器 内 发 出 后 ， 经 过 docker0， 并且 还 需要 在 docker0 处 发 往 
docker0， 最 终 转向 目标 容 右 。 换 言 之 ,从 docker0 出 来 的 数据 包 ， 
如 果 需 要 继续 发 往 docker0， 则 说 明 是 Docker 容 器 间 的 通信 数据 包 。 
使 用 命令 如 下 : 


iptables -I FORWARD -i docker0 -o docker0 -j ACCEPT 


3) 人 允许 接受 从 容器 发 出 ， 且 目 标 地 址 不 是 容器 的 数据 包 。 换 言 
之 ， 人 允许 所 有 从 docker0 发 出 且 不 是 继续 发 向 docker0 的 数据 包 ,使 
用 命令 如 下 : 


iptables -I FORWARD -i docker0 ! -o docker0 -j ACCEPT 


4) 对 于 发 往 docker0， 并 且 属 于 已 经 建立 的 连接 的 数据 包 ， 
Docker 无 条 件 接受 这 些 连 接 上 的 数据 包 ， 使 用 命令 如 下 : 


iptables -I FORWARD -o dockerg0 -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT 


4.7.3 局 用 系统 数据 包 转 发 功能 


在 Linux 系 统 上 ， 网络 设备 之 间 的 数据 包 转 发 功能 是 默认 禁止 
的 。 数 据 包 转发 ， 即 当 宿 主机 存在 多 块 网 络 设备 时 ， 如 果 其 中 一 块 网 
络 设备 接收 到 数据 包 ， 则 无 条 件 将 其 转发 给 另外 的 网 络 设备 。 通 过 修 
改 /proc/sys/netipv4/ip_ forward 的 值 ,将 其 置 为 1, 则 可 以 保证 系 
统 内 数据 包 可 以 实现 转发 功能 ， 代 码 如 下 : 


if ipForward { 
// Enable IPv4 forwarding 


if err := ioutil.WriteFile("/proc/sys/net/ipv4/ip forward", [lbyte{'1', 
'\n'}, 0644); err != nil { 


job.Logf ("WARNING: unable to enable IPv4 forwarding: %s\n", err) 


4.7.4 创建 DOCKER 链 


Docker 在 网 桥 设备 上 创建 一 条 名 为 DOCKER 的 链 ， 该 链 的 作用 
是 在 创建 Docker 容 器 时 实现 容器 与 宿主 机 的 端口 映射 。 实 现代 码 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver/driver 
if err := iptables.RemoveExistingChain("DOCKER"); err != nil { 
return job.Error(err) } 
if enableIPTables { 
chain, err := iptables.NewChain("DOCKER", bridgeIlface) if err != nil { 


return job.Error(err) } 


portmapper.SetIptablesChain(chain) } 


4.7.5 注册 处 理 方法 至 Engine 


创建 完 网 桥 ， 并 配置 完 基本 的 iptables 规 则 之 后 ,Docker 
Daemon 在 网 络 方面 还 向 Engine 中 注册 了 4 个 处 理 方法 ,这些 处 理 方 
法 的 名 称 与 作用 如 下 : 


'allocate _interface : 为 Docker 容 器 分 配 专属 网 络 接口 ， 分 配 
容 希 网 段 的 IP 地 址 ; 


realease _ interface : 释放 Docker 容 器 占用 的 网 络 接口 资源 ; 
"allocate_port : 为 Docker 容 妖 分 配 一 个 靖 口 ; 


link : 实现 Docker 容 希 间 的 连接 操作 。 


4.8 创建 graphdb 并 初始 化 


graphdb 是 一 个 构建 在 SQLite 之 上 的 图 形 数据 库 ， 通 常用 来 记录 
节点 命名 以 及 节点 之 间 的 关联 。 在 Docker 的 世界 中 ,用户 可 以 通过 
link 操 作 ， 使 得 Docker 容 器 之 间 建 立 一 种 关联 ,而 Docker Daemon 
正 是 使 用 graphdb 来 记录 这 种 容 希 间 的 关联 信息 。Docker 创 建 
graphdb 的 产 码 如 下 : 


graphdbPath := path.Join(config.Root, "linkgraph.db") 
graph, err := graphdb.NewSqliteConn(graphdbPath) 
if err != nil { 


return nil, err 


以 上 代码 首先 确定 graphdb 的 目录 
为 /var/lib/docker/linkgraph.db ; 随后 通过 graphdb 包 内 的 
NewsdqliteConn 打 开 graphdb , 使 用 的 驱动 为 sqlite3 ,数据 源 的 名 
称 为 /var/lib/docker/linkgraph.db ; 最 后 通过 NewDatabase 负 数 
初始 化 整个 graphdb ,为 graphdb 创 建 entity 表 和 edge 表 ， 并 在 这 
两 个 表 中 初始 化 部 分 数据 。NewSqliteConn 疯 数 的 实现 位 


于 ./docker/docker/pkg/graphdb/conn_sqlite3.90o ,代码 实现 如 


下 : 


func NewSqliteConn(root string) (*Database, error) { 


conn, err := sql.0pen("sqlite3", root) 


return NewDatabase(conn, initDatabase) 


4.9 创建 execdriver 


execdriver 是 Docker 中 用 来 执行 Docker 容 器 任务 的 驱动 。 创 建 
并 初始 化 graphdb 之 后 , Docker Daemon 随 即 开始 创建 了 
execdriver ,具体 源码 如 下 : 


ed, err := execdrivers.NewDriver(config.ExecDriver, config.Root, sysInitPath, 
sysInfo) 


分 析 以 上 源码 可 知 ，DockerDaemon 创 建 execdriver 时 ， 需 要 
以 下 四 部 分 信息 。 


:config.ExecDriver : Docker 运 行 时 中 用 户 指定 使 用 的 
execdriver 类 型 ， 在 默认 配置 文件 中 值 为 native。 用 户 也 可 以 在 启动 
DockerDaemon 将 这 个 值 配 置 为 lxc， 则 导致 Docker 使 用 |xc 类 型 的 
驱动 执行 Docker 容 器 的 内 部 操作 。 


:config.Root : Docker 运 行 时 的 root 路 径 ， 上 默认 配置 文件 中 
为 /var/lib/docker。 


'SySslnitPath : 系统 中 存放 dockerinit 二 进 制 文件 的 路 径 ， 一 般 
为 /varlib/dockerinit/dockerinit-1.2.0。 


'Syslnfo : 系统 功能 信息 ， 包 括 : 容 怖 的 内 存 限 制 功 能 ， 交 换 区 
内 存 限 制 功 能 ， 数 据 转发 功能 ， 以 及 AppArmor 安 全 功能 


在 执行 execdrivers.NewDriver 之 前 ,首先 通过 以 下 代码 ， 获 取 
期 望 的 目标 dockerinit 文 件 的 路 径 localPath ， 以 及 系统 中 dockerinit 
文件 实际 所 在 的 路 径 syslnitPath : 


localCopy := path.Join(config.Root, "init", fmt.Sprintf("dockerinit-%s", 
dockerversion.VERSION)) 
sysInitPath := utils.DockerInitPath(localCopy) 


通过 执行 以 上 代码 ， localCopy 
为 /var/lib/docker/init/dockerinit-1.2.0 , 而 sysylnitPath 为 当前 
Docker 和 运行 时 中 dockerinit-1.2.0 实 际 所 处 的 路 径 ， 
utils.DockerlnitPath 实 现 位 于 ./docker/docker/utils/util.go。 若 
localCopy 与 sysylnitPath 不 相等 ， 则 说 明 当 前 系统 中 的 dockerinit 
二 进 制 文件 ， 不 在 localCopy 路 径 下 ， 则 需要 将 其 复制 至 localCopy 
下 ， 并 对 该 文件 设 定 权 限 。 


设 定 完 dockerinit 二 进 制 文件 的 位 置 之 后 ,Docker Daemon 创 
建 sysinfo 对 象 ， 记 录 系 统 的 功能 属性 。Syslnfo 的 定义 位 
于 ./dockerdockerpkg/sysinfo/sysinfo.go， 如 下 所 示 : 


type SysInfo struct { 
MemoryLimit bool 
SwapLimit bool 
IPv4ForwardingDisabled bool 


AppArmor bool 


其 中 Docker Daemon 通 过 判断 cgroups 文 件 系 统 挂 载 路 径 下 
ee 
文件 来 为 MemoryLimit 赋 值 ， 若 均 存 在 , 则 管 为 true , 否则 置 为 
false ; 通过 判断 memory.memsw.limit_in_bytes 文 件 是 否 存 在 来 
为 SwapLimit 赋 值 ， 若 该 文件 存在 ， 则 置 为 true， 人 否则 置 为 false。 
AppArmor 的 值 则 是 通过 往 主 机 上 是 否 存 
在 /sys/kernel/security/apparmor 来 判断 ， 知 存在 ， 则 置 为 true ， 
含 则 置 为 false。 


执行 execdrivers.NewDriver 时 , 返回 execdriverDriver 对 象 
实例 ,具体 代码 实现 位 
村./docker/docker/daemon/execdriver/execdrivers/execdriver 
5.90， 由 于 选择 使 用 native 作 为 exec 驱 动 ， 故 执行 以 下 代码 ， 返回 最 
终 的 execdriver ,其 中 native.NewDriver 实 现 位 


于 ./docker/docker/daemon/execdriver/native/driver.go : 


return native.NewDriver(path.Join(root, "execdriver", "native"), initPath) 


至 此 , 一 个 execdriver 的 实例 ed 被 Docker 成 功 创建 。 


4.10 创建 daemon 实 例 


Docker Daemon 在 经 过 以 上 多 个 环节 的 设置 之 后 ,整合 众多 已 
经 创建 的 对 象 ， 创 建 最 终 的 Daemon 对 象 实例 daemon。Daemon 对 
象 实例 daemon 涉 及 的 内 容 极 多 ,比如 : 对 于 Docker 镜 像 的 存储 可 以 
通过 graph 来 管理 、 所 有 Docker 容 莫 的 元 数据 信息 都 保存 在 
containers 对 象 中 、 整 个 Docker Daemon 的 任务 执行 位 于 eng 属 性 
中 ,等 等 。 


创建 daemon 实 例 的 源码 实现 如 下 : 


daemon := &Daemont{ 


repository: daemonRepo, 
containers: &contStore{s: make(map[string]*Container)}, 
graph: 
repositories: repositories, 
idIndex: truncindex.NewTruncIndex([]string{}), 
sysIinfo: sysIinfo, 
volumes: volumes, 
config: config, 
containerGraph: graph, 
driver: driver， 
sysInitPath: sysInitPath, 
execDriver: ed, 
eng: eng, 
} 


分 析 Daemon 类 型 的 属性 如 表 4-1 所 示 。 


表 4-1 Daemon 类 型 属性 分 析 表 


作用 
存储 所 有 Docker 容器 信息 的 路 径 ， 默 认为 /var/lib/docker/containers 
用 于 存储 Docker 容器 信息 的 对 象 


属性 名 


repository 





containers 


( 续 ) 

















属性 名 作用 
graph 存储 Docker 镜像 的 graph 对 象 
Tepositories 存储 本 机 所 有 Docker 镜像 repo 信息 的 对 象 
idIndex 用 于 通过 简短 有 效 的 字符 串 前 级 定位 唯一 的 镜像 
sysInfo 系统 功能 信息 
volumes 管理 宿主 机 上 volumes 内 容 的 graphdriver， 默 认为 vfs 类 型 
config Config.go 文件 中 的 配置 信息 ， 以 及 执行 后 产生 的 配置 DisableNetwork 
containerGraph 存放 Docker 镜像 关系 的 graphdb 
driver 管理 Docker 镜像 的 驱动 graphdriver， 默 认为 aufs 类 型 
sysInitPath 系统 dockerinit 二 进 制 文件 所 在 的 路 径 
execDriver Docker Daemon 的 exec 驱动 ， 默 认为 native 类 型 


eng 


Docker 的 执行 引擎 Engine 类 型 


4.11 检测 DNS 配 直 


创建 完 Daemon 类 型 实例 daemon 之 后 , Docker Daemon 使 用 
daemon.checkLocaldns( ) 检测 Docker 运 行 环境 中 DNS 的 配置 ， 
checkLocaldns 哆 数 的 定义 位 
于 ./docker/docker/daemon/daemon.go#L854-L856 ,代码 如 


func (daemon *Daemon) checkLocaldns() error { 
resolvConf, err := resoLvconf .Get() 
if err != nil { 


return err 


if len(daemon.config.Dns) == 0 && utils.CheckLocalDns(resolvConf) { 


log.Infof("Local (127.0.0.1) DNS resolver found in resolv.conf and 
containers can't use it. Using default external servers : %v", DefaultDns) 


daemon.config.Dns = DefaultDns 


return nil 


以 上 代码 首先 通过 resolvconf.Get( ) 方法 获取 宿主 
机 /etc/resolv.conf 中 的 DNS 服务 钴 信息 。 若 人 宵 主 机 上 DNS 文件 
resolv.conf 中 有 127.0.0.1 , 而 Docker 容 器 在 自身 内 部 不 能 使 用 该 
地 址 ， 故 采用 默认 外 在 DNS 服 务 颖 ,为 8.8.8.8 ,8.8.4.4 ; 若 答 主机 
上 的 resolv.conf 有 Docker 容 器 可 以 使 用 的 DNS 服务 器 地 址 ， 则 
Docker Daemon 采 用 该 地 址 。 最 终 Docker Daemon 将 DNS 服 务 器 
地 址 赋值 给 config 文 件 中 的 Dns 属 性 。 用 户 通过 Docker Daemon 创 
建 Docker 容 器 时 ， 若 不 指定 DNS 服 务 器 地 址 ， 则 Docker Daemon 
将 会 使 用 daemon.Config.Dns 作 为 容器 内 部 的 DNS 服务 器 地 址 。 


4.12 ”启动 时 加 载 已 有 Docker 容 器 


在 Docker Daemon 重 启 时 ,很 有 可 能 之 前 有 遗留 的 Docker 容 
器 。 对 于 这 部 分 容器 ，DockerDaemon 重 启 前 ， 一直 将 元 数据 信息 
存储 在 daemon.repository( 目录 为 /var/lib/docker/containers) 
中 。 为 了 保证 重启 之 后 Docker 容 器 的 信息 不 丢失 ，DockerDaemon 
首先 会 进入 该 目录 去 查看 ， 是 人 否 存在 遗留 的 Docker 容 如 。 若 存在 ， 则 
Docker Daemon 加 载 这 部 分 容器 ， 将 容器 信息 收集 ,并 做 相应 的 维 
I 


Docker Daemon 加 载 Docker 容 器 的 源码 实现 位 
于 ./docker/docker/daemon/daemon.go#L854-L856 , 如 下 : 


if err := daemon.restore(); err != nil { 
return nil, err 
} 


需要 注意 的 是 : 由 于 Docker Daemon 的 重启 不 会 重启 所 有 重启 
前 运行 的 容 硕 ， 故 Docker Daemon 加 载 已 有 容器 时 ， 会 判断 容 铸 之 
前 的 状态 是 否 为 运行 ， 若 是 的 话 ， 会 将 该 容 右 的 状态 置 为 退出 ， 并 在 
内 存 中 的 容器 对 象 以 及 config.json 文 件 中 将 容器 主 进程 的 PID 设 为 
0。 


4.13 设置 shutdown 的 处 理 方法 


加 载 完 已 有 Docker 容 器 之 后 ,Docker Daemon 设 置 了 多 项 在 
shutdown 操 作 中 需要 执行 的 处 理 方法 。 也 就 是 说 , 当 Docker 
Daemon 接 收 到 特定 信号 ， 需 要 执行 shutdown 操 作 时 ， 先 执行 这 些 
处 理 方法 完成 善后 工作 ， 最终 再 实现 物理 意义 上 的 shutdown。 实 现 
源码 如 下 : 


eng.OnShutdown(func() { 
if err := daemon.shutdown(); err != nil { 
log.Errorf("daemon.shutdown(): %s", err) 


if err := portallocator.ReleaseAll(); err != nil { 
log.Errorf("portallocator.ReleaseAll(): %s", err) 


if err := daemon.driver.Cleanup(); err != nil { 
log.Errorf("daemon.driver.Cleanup(): %s", err.Error()) 
} 


if err := daemon.containerGraph.Close(); err != nil { 
log.Errorf("daemon.containerGraph.Close(): %s", err.Error()) 


由 以 上 源码 可 见 ，eng 对 象 Shutdown 操 作 执 行 时 ， 需 要 执行 以 
上 作为 参数 的 func( ) ...…. } 六 数 。 在 该 函数 中 ， 主 要 完成 以 下 4 部 
分 操作 : 


运行 daemon 对 象 的 shutdown 辑 数 ,做 daemon 方 面 的 善后 工 
TE 


:通过 portallocator.ReleaseAll( ) ,释放 所 有 之 前 占用 的 端口 


资源 。 


:通过 daemon.driver.Cleanup( ) ,通过 graphdriver 实 现 
unmount 所 有 有 关 镜 像 layer 的 挂 载 点 。 


:通过 daemon.containerGraph.Close( ) 关闭 graphdb 的 连 
接 。 


4.14 返回 daemon 对 象 实例 


当 所 有 的 工作 完成 之 后 ，Docker Daemon 返 回 daemon 实 例 ， 
意味 着 NewDaemon 隙 数 执行 完毕 ， 程序 运行 最 终 返 回 至 


mainDaemon( ) 中 ,继续 通过 goroutine 完 成 加 载 daemon。 


4.15 总 结 


本 章 从 源码 的 角度 深度 分 析 了 Docker Daemon 局 动 过 程 中 
daemon 对 象 的 创建 与 加 载 。 在 这 一 环节 中 涉及 内 容 极 多 ， 本章 着 重 
归纳 总 结 daemon 实 现 的 逻辑 , 一 一 深入 ， 具 体 全 面 。 


在 Docker 的 架构 中 ，Docker Daemon 的 内 容 是 最 为 丰富 全 面 
的 ,而 NewDaemon 的 实现 涵盖 了 Docker Daemon 启 动 过 程 中 的 大 
部 分 工作 。 可 以 认为 NewDaemon 是 Docker Daemon 实 现 过 程 中 的 
核心 所 在 。 深 入 理解 NewDaemon 的 实现 ， 即 掌握 了 Docker 
Daemon 运 行 的 来 龙 去 脉 。 


第 5 童 ”Docker Server 的 创建 


5.1 引言 


Docker 架 构 中 ,Docker Server 是 Docker Daemon 的 重要 组 
成 部 分 。Docker Server 最 主要 的 功能 是 : 接收 用 户 通过 Docker 
Client 发 送 的 请 求 ， 并 按照 相应 的 路 由 规则 实现 请 求 的 路 由 分 发 ， 最 
终 将 请 求 处 理 后 的 结果 返回 至 Docker Client。 


同时 ,Docker Server 具 备 十 分 优秀 的 用 户 友 好 性 ， 多 种 通信 协 
议 的 支持 大 大 降低 Docker 用 户 使 用 Docker 的 门槛 。 除 此 之 外 ， 
Docker Server 设 计 实 现 了 详尽 清晰 的 API 接 月 ， 以 供 Docker 用 户 使 
用 。 通 信安 全 方面 , Docker Server 可 以 提供 安全 传输 层 协议 
( TLS) ， 保 证 Docker Client 与 Docker Server 之 间 数 据 的 加 密 传 
输 。 并 发 处 理 方面 ，Docker Daemon 大 量 使 用 了 Go 语言 中 的 协 程 
goroutine， 大 大 提高 了 服务 端 对 于 请 求 的 并 发 处 理 能 力 。 


本 章 将 从 源码 的 角度 分 析 Docker Server 的 创建 ， 分 析 内 容 的 安 
排 如 下 : 


1) 介绍 J]ob“serveapi” 的 创建 与 执行 流程 ,代表 Docker 
Server 的 创建 。 


2) 深入 分 析 Job"“serveapi” 的 执行 流程 。 


3) 分 析 Docker Server 创 建 Listener 并 服务 API 的 流程 。 


5.2 Docker Server 创 建 流程 


我 们 在 第 3 章 主要 分 析 了 Docker Daemon 的 启动 , 而 在 
mainDaemon( ) 运行 的 最 后 环节 , Docker 实 现 了 创建 并 运行 名 为 
serveapi 的 Job。 这 一 环节 的 作用 是 : 让 Docker Daemon 提 供 API 访 
问 服务 。 实 质 上 ， 这 正 是 实现 了 Docker 染 构 中 Docker Server 的 创 


建 与 运行 。 


从 流程 的 角度 来 说 ，Docker Server 的 创建 与 运行 ， 代表 了 
Job“serveapi” 的 整个 生命 周期 。 整 个 生命 周期 包括 : 创建 Docker 
Server 的 job ,配置 jJob 环 境 变量 ， 以 及 触发 执行 job。 


5.2.1 创建 名 为 “serveapi” 的 Job 


Docker 梁 构 中 ，Job 是 Engine 内 部 最 基本 的 任务 执行 单位 。 创 建 
Docker Server , 服务 于 API 请 求 ， 同样 属于 Docker 内 部 的 一 项 任 
务 。 因 此 ， 这 一 任务 同样 需要 表示 为 一 个 可 执行 的 ob。 换 言 之 ， 需 
要 创建 Docker Server，, 则 必须 创建 一 个 相应 的 Job。 具 体 的 Job 创 建 
形式 位 于 ./docker/docker/docker/daemon.go#L66 ,如 下 所 示 : 


job := eng.Job("serveapi", flHosts...) 


以 上 代码 通过 Engine 实 例 eng 创 建 一 个 Job 类 型 的 实例 job , Job 
实例 名 为 serveapi ,同时 用 flHosts 的 值 初始 化 job.Args。flHosts 的 
作用 是 : 配置 Docker Server 监 听 的 协议 与 监听 的 地 址 。 


需要 注意 的 是 ， 第 3 章 中 曙 数 mainDaemon( ) 的 具体 实现 过 程 
中 ， 在 加 载 builtins 环 节 已 经 向 eng 对 象 注册 了 键 为 Serveapi 的 处 理 
方法 ， 而 该 处 理 方法 的 值 为 api.ServeApi。 因 此 ， 在 运行 名 为 
serveapi 的 Job 时 ， 会 执行 该 job 的 处 理 方法 api.,ServeApi。 


5.2.2 ”配置 job 环境 变量 


创建 完 job 实 例 job 之 后 , Docker Daemon 为 job 实例 配置 环境 参 
数 。 在 Job 的 实现 过 程 中 ,为 job 配置 参数 的 方式 有 两 种 : 第 一 种 ， 创 
建 Job 实 例 时 ， 用 指定 参数 直接 初始 化 job 的 Args 属 性 ; 第 二 种 ， 创 建 
完 job 后 ， 给 job 添加 指定 的 环境 变量 。 以 下 源码 实现 了 为 创建 的 job 配 
置 环 境 变 量 。 


job.SetenvBool ("Logging", true) 
job.SetenvBool ("EnableCors", *flEnableCors) 
job.Setenv("Version", dockerversion.VERSION) 
job.Setenv("SocketGroup", *flSocketGroup) 
job.SetenvBool ("Tls", *f1TLls) 

job.SetenvBool ("TlsVerify", *flTLlsVerify) 
job.Setenv("TlsCa", *flCa) 
job.Setenv("TLlsCert", *flCert) 
job.Setenv("TLlsKey", *flKey) 

job.SetenvBool ("BufferRequests", true) 





对 于 以 上 配置 环境 变量 的 归纳 总 结 如 表 5-1 所 示 。 


表 5-1 job 环 境 变 量 列表 






































环境 变量 名 flag 参数 默认 值 作用 值 
Logging 于 true 启用 Docker 容器 的 日 志 输 出 
EnableCors flEnableCors false 在 远程 API 中 提供 CORS 头 
Version 显示 Docker 版 本 号 
SocketGroup flSocketGroup docker 在 daemon 模式 中 unix domain socket 分 配 用 户 组 名 
Tls fiTls false 使 用 TLS 安全 传输 协议 
TlsVerify fTlsVerify false 使 用 TLS 并 验证 远程 客户 端 
TlsCa fca 指定 CA 文件 路 径 
TlsCert flCert TLS 证 书 文件 路 径 
TlsKey | filkey TLS 密 钥 文件 路 径 
BufferRequest true 缓存 Docker Client 请 求 











5.2.3 运行 Job 


创建 完 job ,配置 完 job 的 环境 变量 ,意味 着 DockerServer 的 创 
建 需 求 已 准备 完毕 。 万 事 俱 备 ， 只 欠 东 风 ， 东风 就 是 触发 执行 这 个 
Job。Docker 中 通过 job 实例 的 run 函 数 完 成 job 的 触发 执行 。 触 发 执 
行 Serveapi 这 个 job 的 具体 实现 源码 如 下 : 


if err := job.Run(); err != nil { 
log.Fatal (err) 


由 于 Docke 中 经 在 eng 对 象 中 注册 过 键 为 Serveapi 的 处 理 方 
法 ， 故 在 运行 job 的 时 候 ,执行 这 个 处 理 方 法 的 值 遇 数 ， 相 应 处 理 方法 
的 值 为 api.ServeApi。 至 此 ， 名 为 serveapi 的 job 的 生命 周期 已 经 完 
备 。 本 章 余下 内 容 将 深入 分 析 Job 的 处 理 方法 ，api.ServeApi 的 执行 


细节 。 


5.3 ServeApi 运 行 流程 
ServeApi 属 于 Docker Server 提 供 API 服 务 的 部 分 ， 本 小 节 将 从 
源码 的 角度 剖析 Docker Server 的 架构 设计 与 实现 。 


作为 一 个 监听 请 求 、 处 理 请 求 、 响 应 请 求 的 服务 端 ，Docker 
Server 首 先 需 要 明确 自身 可 以 为 多 少 种 通信 协议 提供 服务 。 稍 加 深入 
学 习 Docker 这 个 C/S 模 式 的 架构 设计 ， 就 可 以 发 现 Docker Server 支 
持 的 协议 包括 以 下 三 种 : TCP 协 议 、UNIX Socket 形 式 以 及 fd 的 形 
式 。 随 后 ,Docker Server 根 据 协议 的 不 同 ， 分 别 创建 不 同 的 服务 端 
实例 。 最 后 ， 在 不 同 的 服务 端 实例 中 ， 创 建 相 应 的 路 由 模块 、 监 听 模 
块 ， 以 及 处 理 请 求 的 处 理 方法 ， 形 成 一 个 完备 的 服务 端 。 


serveapi 这 个 J]ob 在 运行 时 ,将 执行 api.ServeApi 隙 数 。 
ServeApi 的 功能 是 : 循环 检查 Docker Daemon 当 前 支持 的 所 有 通信 
协议 ， 并 为 每 一 种 协议 都 创建 一 个 协 程 goroutine， 并 在 此 协 程 内 部 
配置 一 个 服务 于 HTTP 请 求 的 服务 端 。ServeApi 的 源码 实现 位 
于 ./dockerdockerapi/serverservergo#L1339 ,如 下 所 示 : 


func ServeApi(job *engine.Job) engine.Status { 
if len(job.Args) == 0 { 
return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", 
job.Name) 
} 


var ( 
protoAddrs = job.Args 
chErrors = make(chan error, len(protoAddrs)) 


) 
activationLock = make(chan struct{}) 
for , protoAddr := range protoAddrs { 
protoAddrParts := strings.SplitN(protoAddr, "://", 2) 
if len(protoAddrParts) != 2 { 
return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", 
job.Name) 


} 
go func() { 
log.Infof("Listening for HTTP on %s (%s)", protoAddrParts[0], 
protoAddrParts[1]) 
chErrors <- ListenAndServe(protoAddrParts[0], 
protoAddrParts[1], job) 
}() 


} 
for i := 0; i < len(protoAddrs); i += 1 1{ 
err := <-chErrors 
if err != nil { 
return job.Error(err) 
} 


return engine.StatusOK 


~ 


分 析 以 上 源码 ， 通 过 模块 化 的 划分 ， 我 们 可 以 发 现 ServeApi 的 执 
行 流程 主要 分 为 以 下 4 个 步 又 : 


检验 job 的 参数 ， 确 保 传 入 参数 无 误 


2) 定义 Docker Server 的 监听 协议 与 地 址 ， 以 及 错误 信息 管道 


channel。 
遍历 协议 地 址 ， 针 对 协议 创建 相应 的 服务 端 。 
4) 通过 chErrors 建 立 goroutine 与 主 进程 之 间 的 协调 关系 。 


下 面 详 细 分 析 以 上 4 个 步骤 : 


第 一 , Docker Daemon 判 断 job 的 参数 ， 保 证 传 入 的 job 参数 无 
误 。DockerDaemon 判 断 的 依据 来 源 于 job.Args 的 长 度 。 由 于 
Docker 创 建 serveapi 这 个 Job 时 ,通过 flHosts 来 初始 化 job.Args ， 
故 job.Args 为 相当 于 数组 人 IHost , 若 flHost 的 长 度 为 0 , 则 说 明 
Docker Server 没 有 监听 的 协议 与 地 址 ， 参 数 有 误 ,退回 错误 信息 。 
源码 如 下 : 


if len(job.Args) == 0 { 
return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", job.Name) 
} 


第 二 , 定义 protoAddrs、chErrors 与 activationLock 三 个 变 
量 ， 分别 代 表 Docker Server 监 听 的 协议 与 地 址 ,以 及 job 间 的 同步 


channel, 


protoAddrs 代 表 flHosts 的 内 容 ; 而 chError 定 义 了 和 
protoAddrs 长 度 一 致 的 错误 类 型 管道 ，chError 的 作用 会 在 下 文中 说 
明 。 同 时 定义 的 变量 activationLock , 是 用 以 同步 serveapi 和 
acceptconnections 这 两 个 job 执行 的 管道 。serveapi 运 行 时 ， 
ServeFd 和 ListenAndServe 国 数 均 由 于 activationLock 中 没有 内 容 
而 阻塞 ， 而 当 运 行 acceptionconnections 这 个 job 时 ,该 job 会 首先 
通知 init 进 程 Docker Daemon 已 经 启动 完毕 ， 并 关闭 
activationLock ,因此 ServeFd 以 及 ListenAndServe 不 再 阻塞 , 结 
果 是 serveapi 继 续 执行 。 正 是 由 于 activationLock 的 存在 ,Docker 


Daemon 可 以 保证 acceptconnections 这 个 job 的 运行 有 能 力 通知 
serveapi 开 局 正式 服务 于 API 请 求 的 功能 。 源 码 如 下 : 


Var ( 
protoAddrs = job.Args 
chErrors = make(chan error, len(protoAddrs)) 


) 
activationLock = make(chan struct{}) 


第 三 , 遍历 协议 地 址 ,针对 协议 创建 相应 的 服务 端 。 协 议 地 址 即 
protoAddrs , 也 就 是 job.Args。DockerDaemon 将 protoAddrs 的 
每 一 元 素 都 按照 子 符 串 ”: // 进行 分 割 ， 若 分 割 后 protoAddrParts 的 
长 度 不 为 2， 则 说 明 协议 地 址 的 书写 形式 有 误 ,返回 job 错误 ; 若 分 制 
后 protoAddrParts 的 长 度 为 2， 则 说 明 地 址 协议 符合 标准 ， 获 取 
protoAddrParts 中 的 协议 protoAddrParts[0] 与 地 址 
protoAddrParts[1]。 最 后 ， 针 对 每 一 次 循环 中 获得 的 协议 与 地 址 ， 
Docker Daemon 均 创建 一 个 goroutine 来 执行 ListenAndServe 的 
操作 。goroutine 的 运行 主要 依赖 于 ListenAndServe 
( protoAddrParts[0] , protoAddrParts[1] , job) 的 运行 结果 。 若 
ListenAndServe 返 回 错误 ， 则 chErrors 中 有 错误 ,当前 协 程 执 行 完 
毕 ; 和 若 没有 返回 错误 ， 则 该 协 程 持续 运行 ， 持 续 提 供 服 务 。 其 中 最 为 
重要 的 是 ListenAndServe 的 实现 ， 该 函数 具体 实现 了 Docker 
Daemon 如 何 创建 listener、router 以 及 server ,并 协调 三 者 进行 工 
作 ， 最 终 服务 于 API 请 求 。 步 又 三 的 源码 实现 如 下 : 


for , protoAddr := range protoAddrs { 
_protoAddrParts := strings.SplitN(protoAddr, "://", 2) 
if Len(protoAddrParts) != 2 { 
return job.Errorf("usage: %s PROTO://ADDR [PROTO://ADDR ...]", 
job.Name) 
} 


go func() { 
log.Infof("Listening for HTTP on %s (%s)", protoAddrParts[0], 
protoAddrParts[1]) 
chErrors <- ListenAndServe(protoAddrParts[0], protoAddrParts[1], job) 


}() 


第 四 ， 根 据 chErrors 的 值 运行 ， 若 chErrors 这 个 管道 中 有 错误 内 
容 ， 0 ; 若 无 错误 内 容 ， 则 循环 被 阻塞 。 
chErrors 这 个 管道 的 作用 是 : 确保 ListenAndServe 所 对 应 的 协 程 能 
ss 了 协调 ,如果 协 程 运行 出 错 ， 主 哨 数 ServeApi 
仍然 可 以 捕获 这 样 的 错误 ， 从 而 导致 程序 的 退出 。 实 现 源码 如 下 : 


for i := 0; i < len(protoAddrs); i += 1 { 
err := <-chErrors 
if err != nil { 
return job.Error(err) 
} 
} 


return engine.StatusOK 


至 此, ServeApi 的 运 云 行 流程 已 经 全 部 分 析 完 毕 ， 其 中 核心 部 分 
ListenAndServe 的 实现 ， 将 在 5.4 节 深入 分 析 。 


5.4 ListenAndServe 实 现 


ListenAndServe 的 功能 是 : 使 Docker Server 监 听 革 一 指定 地 
址 ， 并 接收 该 地 址 上 的 请 求 ， 并 对 以 上 请 求 路 由 转发 至 相应 的 处 理 方 
法 处 。 从 实现 的 角度 来 看 ,ListenAndServe 主 要 实现 了 设置 一 个 服 
务 于 HTTP 协 议 请 求 的 服务 端 ， 该 服务 端 监 听 指 定 地 址 上 的 请 求 ， 并 
对 请 求 做 特定 的 协议 检查 ， 最 终 完 成 请 求 的 路 由 与 分 发 。 代 码 实 现 位 


于 ./docker/docker/api/server/server.go., 
ListenAndServe 的 实现 可 以 分 为 以 下 4 个 部 分 : 
1) 创建 router 路 由 实例 。 
2) 创建 listener 监 听 实 例 。 
3) 创建 http.Server。 
4) 局 动 API 服 务 。 


ListenAndServe 的 执行 流程 如 图 5-1 所 示 。 


listenbuffer. 
NewListenButfenr' 





图 5-1 ListenAndServe 执 行 尝 程 图 


本 节 将 按照 ListenAndServe 执 行 流 程 图 一 一 深入 分 析 各 个 部 
分 Le) 


5.4.1 创建 router 路 由 实例 


首先 ， 在 函数 ListenAndServe 的 实现 过 程 中 ,Docker 通 过 
createRouter 创 建 了 一 个 router 路 由 实例 。 代 码 源码 如 下 : 


r, err := createRouter(job.Eng, job.GetenvBool ("Logging"), 
job.GetenvBool ("EnableCors"), job.Getenv("Version")) 
if err != nil { 

return err 


createRouter 的 实现 位 
于 ./docker/docker/api/server/server.go#L1094, 


创建 router 路 由 实例 是 一 个 重要 的 环节 ， 路 由 实例 的 作用 是 : 负 
责 Docker Server 对 外 部 请 求 的 路 由 以 及 分 发 。 在 实现 过 程 中 ， 有 两 
个 主要 步 又 : 第 一 ， 创 建 全 新 的 router 路 由 实例 ; 第 二 ， 为 router 实 
例 添 加 路 由 记录 。 


1. 创 建 空 路 由 实例 


实 原 上 ,createRouter 通 过 包 gorilla/mux 来 实现 一 个 功能 强大 
的 路 由 硕 和 分 发 项。 源码 实现 如 下 : 


r := mux.NewRouter() 


NewRouter( ) 函数 返回 了 一 个 全 新 的 router 实 例 r。 在 创建 
Router 实 例 时 ， 给 Router 对 象 实例 的 两 个 属性 进行 赋值 ， 分 别 为 
nameRoutes 和 KeepContext。 其 中 namedRoutes 属 性 为 map 类 
型 ， 键 为 string 类 型 ， 值 为 Route 路 由 记录 类 型 ; 另外 ， 
KeepContext 属 性 为 false ， 表 示 Docker Server 在 处 理 完 请 求 之 
后 ， 就 清除 请 求 的 内 容 ， 不 对 请 求 做 存储 操作 。 源 码 位 
于 ./dockervdockervvendorsrc/github.com/gorilla/mux/mux.go 


#L16 ,如 下 所 示 : 


func NewRouter() *Router { 
return ARouter{fnamedRoutes: make(map[string]*Route), KeepContext: false} 


} 


可 见 ,以 上 代码 返回 的 类 型 为 nux.Router。mux.Router 会 通 
过 一 系列 已 经 注册 过 的 路 由 记录 ， 来 匹配 接收 的 请 求 。 首 先 通过 请 求 
的 URL 或 者 其 他 条 件 ， 找 到 相应 的 路 由 记录 ， 并 调用 这 条 路 由 记录 中 
的 执行 处 理 方法 。mux.Router 有 以 下 特性 : 


请求 可 以 基于 URL 的 主机 名 、 路 径 、 路 径 前 缀 、shemes、 请 求 
头 和 请 求 值 、HTTP 请 求 方法 类 型 或 者 使 用 自 定义 的 匹配 规则 。 


'URL 主 机 名 和 路 径 可 以 通过 一 个 正则 表达 式 来 表示 。 


注册 的 URL 可 以 被 直接 运用 ， 也 可 以 被 保留 ， 从 而 保证 维护 资源 
的 使 用 。 


:路 由 记录 同样 可 以 作用 于 子路 由 记录 : 如 果 父 路 由 记录 匹配 ， 则 
从 套 记录 只 会 被 用 来 测试 。 当 设计 一 个 组 内 的 路 由 记录 共享 相同 的 匹 
配 条 件 时 ， 如 主机 名 、 路 径 前 缀 或 者 其 他 重复 的 属性 ， 子 路 由 的 方式 
会 起 到 相应 的 效果 。 


:mux.Router 实 现 了 http.Handler 接 口 ， 故 和 标准 的 
http.ServeMux 兼 容 。 


2. 添 加 路 由 记录 


Router 路 由 实例 r 创 建 完 毕 ,下 一 步 工 作 是 为 Router 实 例 r 添 加 所 
需要 的 路 由 记录 。 路 由 记录 存储 着 用 来 匹配 请 求 的 信息 ， 包 括 对 请 求 
的 匹配 规则 , 以 及 匹配 之 后 的 处 理 方 法 执行 入 口 。 


回 到 createRouter 实 现 源 码 中 ，Docker 首 先 判断 Docker 
Daemon 的 启动 过 程 中 有 没有 开启 DEBUG 模 式 。 通 过 docker 可 执行 
文件 局 动 Docker Daemon ,解析 flag 参 数 时 , 若 fIDebug 的 值 为 
false， 则 说 明 不 需要 配置 DEBUG 环 境 ; 若 fIDebug 的 值 为 true ,， 则 
说 明 需 要 为 Docker Daemon 添 加 DEBUG 功 能 。 具 体 的 源码 实现 如 
下 : 


if os.Getenv("DEBYUG") != "" { 
AttachProfiler(r) 


AttachProiler( r) 的 功能 是 为 路 由 实例 r 添 加 与 DEBUG 相 关 的 
路 由 记录 ， 具 体 实 现 位 
于 ./dockerdockerapi/serverservergo##L1083 ,如 下 所 示 : 


func AttachProfiler(router *mux.Router) { 
router.HandleFunc("/debug/vars", expvarHandler) 
router.HandleFunc("/debug/pprof/", pprof.Index) 
router.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline) 
router.HandleFunc("/debug/pprof/profile", pprof.Profile) 
router.HandleFunc("/debug/pprof/symbol", pprof.Symbol) 
router.HandleFunc("/debug/pprof/heap", pprof.Handler("heap").ServeHTTP) 
router.HandleFunc("/debug/pprof/goroutine", 

pprof.Handler("goroutine").ServeHTTP) 

router.HandleFunc("/debug/pprof/threadcreate", pprof.Handler 
("threadcreate") .ServeHTTP) 
} 


分 析 以 上 源码 ， 可 以 发 现 Docker Server 使 用 两 个 包 来 完成 
DEBUG 相 关 的 工作 : expvar 和 pprof。 包 expvar 为 公有 变量 提供 标 
准 化 的 接口 ， 使 得 这 些 公 有 变量 可 以 通过 HTTP 的 形式 
在 “/debug/vars" 这 个 URL 下 被 访问 ， 传 输 格 式 为 SON。 包 pprof 将 
Docker Server 和 运行 时 的 分 析 数 据 通过 “/debug/pprof/ "这 个 URL 向 
外 又 露 。 这 些 运行 时 信息 包括 以 下 内 容 : 可 得 的 信息 列表 、 正 在 运行 
的 命令 行 信息 、CPU 信 息 、 程 序 曙 数 引用 信息 、ServeHTTP 纹 数 三 部 
分 信息 的 使 用 情况 ( 堆 使 用 、 协 程 使 用 和 线程 使 用 ) 。 


再 次 回 到 createRouter 贸 数 实现 中 ,完成 DEBUG 功 能 的 所 有 工 
作 之 后 ， Docker 创 建 了 一 个 映射 类 型 的 对 象 m ,用 于 初始 化 路 由 实例 
r 的 路 由 记录 。 简 化 的 m 对 象 ， 源 码 如 下 : 


m := map[string]jmap[string]HttpApiFunc{ 


"GET": { 
"/events": getEvents, 
"/info": getInfo, 
"/version": getVersion, 
"/images/json": getImagesJSON, 
"/images/viz": getImagesViz, 
"/images/search": getImagesSearch, 
"/images/{name:.*}/get": getImagesGet, 
"/images/{name:.*}/history": getImagesHistory, 
"/images/{name:.*}/json": getImagesByName, 
"/containers/ps": getContainersJSON， 
"/containers/json": getContainersJSON， 

}, 

"POST": { 
"/containers/{name:.*}/copy": postContainersCopy, 

}, 

"DELETE": { 


"/containers/{name:.*}": deleteContainers, 


"/images/{name: .*}": deleteImages, 
}, 
"OPTIONS": { 

""; optionsHandler, 
}, 


对 象 m 的 类 型 为 映射 ， 其 中 键 为 string 类 型 ， 代 表 HTTP 的 请 求 类 
型 ,如 GET、POST、DELETE 等 ， 值 为 另 一 个 映射 类 型 ， 该 映射 代表 
的 是 URL 与 执行 处 理 方法 的 映射 。 在 第 二 个 映射 类 型 中 ， 键 为 string 
类 型 ， 代 表 的 是 请 求 URL , 值 为 HttpApiFunc 类 型 ， 代 表 具 体 的 执行 
处 理 方法 。 其 中 HttpApiFunc 类 型 的 定义 如 下 : 


type HttpApiFunc func(eng *engine.Engine, version version.Version, w 
http.ResponseWriter, r *http.Request, vars map[string]string) error 


完成 对 象 m 的 定义 ， 随 后 Docker Server 通 过 该 对 象 m 来 添加 路 
由 实例 r 的 路 由 记录 。 对 象 m 的 请 求 方 法 、 请 求 URL 和 请 求 处 理 方法 这 
三 样 内 容 可 以 为 对 象 [ 构 建 一 条 路 由 记录 。 源 码 实现 如 下 : 


for method, routes := range m { 


for route, fct := range routes { 
log.Debugf ("Registering %s, %s", method, route) 
localRoute := route 


LocaLFct := fct 
LocaLMethod := method 
f := makeHttpHandler(eng, logging, localMethod, localRoute, 
localFct, enableCors, version.Version(dockerVersion)) 


if localRoute == "" { 
r.Methods (localMethod) .HandLerFunc(f) 
} else { 


r.Path("/v{version:[0-9.]+}" 
LocaLRoute ) .Methods (localMethod) .HandlerFunc(f) 
r.Path(localRoute).Methods (localMethod).HandlerFunc(f) 
} 


分 析 以 上 源码 可 以 发 现 : 在 第 一 层 循 环 中 ， 按 HTTP 请 求 方法 


| 


分 ， 获 得 请 求 方法 各 自 的 路 由 记录 ; 第 二 层 循环 ， 按 匹配 请 求 的 URL 


进行 划分 ， 获 得 与 URL 相 对 应 的 执行 处 理 方法 。 在 柑 套 循环 中 ， 通 过 

makeHttpHandler 返 回 一 个 执行 的 义 数 f。 在 返回 的 这 个 函数 中 ， 

及 T 了 日志 配置 信息 、CORS 信 息 ( 跨 域 资源 共享 协议 ) ， 以 及 版 本 1 
。 下 面 举 例 说 明 makeHttpHandler 的 实现 ， 从 对 象 m 可 以 看 到 ， 


对 于 GET 请 求 ， 请求 URL 为 /info， 则 请 求 处 理 方法 为 getlnfo。 执 行 


makeHttpHandler 的 具体 源码 实现 如 下 : 


func makeHttpHandler(eng *engine.Engine, logging bool, localMethod string, 
localRoute string, handlerFunc HttpApiFunc, enableCors bool, dockerVersion 
version.Version) http.HandlerFunc { 
return func(w http.ResponseWriter, r *http.Request) { 

// log the request 

log.Debugf ("Calling %s %s", localMethod, localRoute) 

if logging { 

log.Infof("%s %s", r.Method, r.RequestURI) 
} 


if strings.Contains(r.Header.Get("User-Agent"), "Docker-Client/") { 
userAgent := strings.Split(r.Header.Get("User-Agent"), "/") 
if len(userAgent) == 2 && 
1dockerVersion.Equal (version.Version(userAgent[1])) { 
log.Debugf ("Warning: client and server don't have the sam 
version (client: %s, server: %s)", userAgent[1], dockerVersion) 


举 


人 
口 


了 


人 


} 
version := version.Version(mux.Vars(r)["version"]) 
if version == "" { 

version = api.APIVERSION 


if enableCors { 
writeCorsHeaders(w, r) 


if version.GreaterThan(api.APIVERSION) { 
http.Error(w, fmt.Errorf("client and server don't have same 
version (client : %s, server: %s)", version, api.APIVERSION) .Error()， 
http.StatusNotFound) 
return 
} 


if err := handlerFunc(eng, version, w, r, mux.Vars(r)); err != nil { 
log.Errorf("Handler for %s %s returned error: %s", 
localMethod, localRoute, err) 
httpError(w, err) 
} 


可 见 makeHttpHandler 的 执行 直接 返回 一 个 级 数 func( Ww 
http.ResponseWriter , r*http.Request) 。 在 func 喘 数 的 实现 
中 ,判断 makeHttpHandler 传 入 的 logging 参 数 ， 若 为 true ， 则 将 
该 处 理 方法 的 执行 日 志 显示 出 来 ; 另外 通过 makeHttpHandler 传 入 
的 enableCors 参 数 判断 是 否 在 HTTP 请 求 的 头 文件 中 添加 跨 域 资源 共 
享 信息 ， 若 为 true， 则 通过 writeCorsHeaders 函 数 向 请 求 响应 中 添 
加 有 关 CORS 的 HTTP Header ,源码 实现 位 
于 ./dockervdockerapi/serverservergo##L1022 ,如 下 所 示 : 


func writeCorsHeaders(w http.ResponseWriter, r *http.Request) { 
w.Header().Add("Access-Control-Allow-Origin", "*") 
w.Header().Add("Access-Control-Allow-Headers", "Origin, X-Requested- 
With, Content-Type, Accept") 
w.Header().Add("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT, 
OPTIONS") 
} 


最 为 重要 的 执行 部 分 为 handlerFunc( eng , version , WwW ,Tr， 
mux.Vars( r) ) ,源码 如 下 : 


if err := handlerFunc(eng, version, w, r, mux.Vars(r)); err != nil { 
log.Errorf("Handler for %s %s returned error: %s", localMethod, 
localRoute, err) 
httpError(w, err) 


对 于 GET 请 求 类 型 ，URL 为 /info 的 请 求 ， 由 于 处 理 方法 名 为 
getlnfo ,也 就 是 说 handlerFunc 这 个 行 参 的 值 为 getinfo， 故 执行 音 
分 直接 运行 getinfo( eng , version , w ,r, mux.Vars( nm ) ,而 
getlnfo 的 具体 实现 位 
于 ./dockerdockerapi/serverserve.go#L269 ,如 下 所 示 : 


func getInfo(eng *engine.Engine, version version.Version, w http.ResponseWriter, 
r *http.Request, vars map[string]string) error { 

w.Header().Set("Content-Type", "application/json") 

eng.ServeHTTP(w, r) 

return nil 


以 上 makeHttpHandler 的 执行 已 经 完毕 ， 返回 func 员 数 ， 作 为 
指定 URL 对 应 的 处 理 方法 。 


创建 完 处 理 员 数 后 , Docker 需 要 向 路 由 实例 添加 新 的 路 由 记录 。 
如 果 URL 信 息 为 空 ， 则 直接 为 该 HTTP 请 求 方法 类 型 添加 路 由 记录 ; 
若 URL 不 为 空 ， 则 为 请 求 URL 路 径 添加 新 的 路 由 记录 。 需 要 额外 注意 
的 是 ， 在 URL 不 为 空 ， 为 路 由 实例 r 添 加 路 由 记录 时 ， 考虑 了 API 版 本 


的 问题 ， 通 过 FrPath( "/v{version : [0- 
9.]+}"+localRoute) .Methods( localMethod) ,HandlerFunc 


( 和 来 实现 。 


至 此 ,mux.Router 实 例 r 的 两 部 分 工作 已 经 全 部 完成 : 创建 空 的 
路 由 实例 r ,为 r 添 加 相应 的 路 由 记录 ，, 最 后 返回 配置 后 的 路 由 实例 r。 


5.4.2 创建 listener 监 听 实 例 


路 由 模块 ， 完 成 请 求 的 路 由 与 分 发 ， 是 ListenAndServe 实 现 中 
的 第 一 项 重要 工作 。 对 于 请 求 的 监听 功能 ， 同 样 需要 模块 来 完成 。 而 
在 ListenAndServe 实 现 中 ， 第 二 项 重要 的 工作 就 是 创建 Listener。 
Listener 是 一 种 面向 流 协议 的 通用 网 络 监听 模块 。 


在 创建 Listener 之 前 ，Docker 先 判断 Docker Server 人 允许 的 协 
议 ， 和 若 协 议 为 fd 形式 ， 则 直接 通过 ServeFd 来 服务 请 求 ; 若 协 议 不 为 
fd 形式 ， 则 继续 往 下 执行 。 


程序 首先 需要 判断 serveapi 这 个 Job 的 环境 中 BufferRequests 的 
值 , 若 为 true , 则 通过 包 listenbuffer 创 建 一 个 Listener 的 实例 | , 否 
则 的 话 直 接 通过 包 net 创 建 Listener 实 例 |。 具 体 的 源码 位 
于 ./docker/docker/api/server/server.go#L1269-L1273 , 如 下 所 


小 : 


if job.GetenvBool("BufferRequests") { 

l, err = listenbuffer.NewListenBuffer(proto, addr, activationLock) 
} else { 

l, err = net.Listen(proto, addr) 
} 


由 于 在 mainDaemon( ) 中 创建 serveapi 这 个 job 之 后 ,给 Job 
添加 环境 变量 时 ， 环 境 变量 BufferRequets 的 值 为 true ， 故 使 用 包 


listenbuffer 创 建 listener 实 例 。 


Listenbuffer 的 作用 是 : 让 Docker Server 立 即 监听 指定 协议 地 
址 上 的 请 求 ， 但 是 将 这 些 请 求 暂时 先 缓存 下 来 ， 等 Docker Daemon 
全 部 启动 完毕 之 后 ， 才 让 Docker Server 开 始 接受 这 些 请 求 。 这 样 设 
计 有 一 个 很 大 的 好 处 ， 那 就 是 可 以 保证 在 Docker Daemon 还 没有 完 
全 启动 完毕 之 前 ， 接 收 并 缓存 尽 可 能 多 的 用 户 请 求 。 


若 协 议 的 类 型 为 TCP， 另 各 ob 中 环境 变量 Tls 或 者 TlsVerify 有 一 
个 为 true ， 则 说 明 Docker Server 需 要 支持 HTTPS 服 务 ，Docker 需 
要 为 Docker Server 配 置 安全 传输 层 协议 ( TLS) 的 支持 。 实 现 TLS 
协议 ， 首 先 需要 建立 一 个 tls.Config 类 型 实例 tlsConfig ,然后 在 
tlsConfig 中 加 载 证 书 、 认 证 信息 等 ， 最 终 通过 tls 包 中 的 
NewListener 贸 数 ， 创 建 出 适应 于 接收 HTTPS 协 议 请 求 的 Listener 实 
例 | , 代码 如 下 : 


l= tls.NewListener(l, tlsConfig) 


至 此 , 创建 网 络 监听 的 Listener 部 分 已 经 全 部 完成 。 


5.4.3 创建 http.Server 


Docker Server 同 样 需要 创建 一 个 Server 对 象 来 运行 
HTTP/HTTPS 服 务 端 。 在 ListenAndServe 实 现 中 第 三 个 重要 的 工作 
就 是 创建 http.Server， 实现 源码 如 下 : 


httpSrv := http.Server{Addr: addr, Handler: r} 


其 中 addr 为 需要 监听 的 地 址 ，r 为 mux.Router 路 由 实例 。 


5.4.4 局 动 API 服 务 


创建 http.Server 实 例 之 后 ,Docker Server 立 即 启 动 API 服 务 ， 
使 Docker Server 开 始 在 Listener 监 听 实 例 | 上 接受 请 求 ， 并 对 于 每 一 
个 请 求 都 生成 一 个 新 的 协 程 来 做 专属 服务 。 对 于 每 一 个 请 求 ， 协 程 会 
读 取 请 求 ， 查询 路 由 表 中 的 路 由 记录 项 ， 找 到 匹配 的 路 由 记录 ， 最终 
调用 路 由 记录 中 的 处 理 方法 ， 执 行 完毕 后 ， 协 程 对 请 求 返回 响应 信 
息 。 代 码 如 下 : 


return httpSrv.Serve(l) 


至 此 ,ListenAndServer 的 所 有 流程 已 经 分 析 完 毕 ，Docker 
Serve 包 经 开始 针对 不 同 的 协议 ， 服 务 API 请 求 。 


5.5 总 结 


Docker Server 作 为 Docker Daemon 架构 中 请 求 的 入 口 ,接管 
了 Docker Client 与 Docker Daemon 之 间 所 有 的 通信 。 通 信 API 的 规 
范 性 ， 通 信 过 程 的 安全 性 ， 服 务 请 求 的 并 发 能 力 ， 往 往 都 是 Docker 用 
户 最 为 关心 的 内 容 。 本 章 基 于 Docker 源 码 ， 分 析 了 Docker Server 
大 部 分 的 细节 实现 。 希 望 Docker 用 户 可 以 初探 Docker Server 的 设 
计 理 念 ， 并且 可 以 更 好 地 利用 Docker Server 创 造 更 大 的 价值 。 


第 6 章 Docker Daemon 网 络 


6.1 引言 


Docker 作 为 一 个 开源 的 轻 量 级 虚拟 化 容 兹 引擎 技术 , 已然 给 云 计 
算 领域 带 来 全 新 的 发 展 模式 。Docker 借 助 容器 技术 彻底 释放 了 轻 量 级 
虚拟 化 技术 的 威力 ， 让 容 妖 的 伸缩 、 应 用 的 运行 都 变 得 前 所 未 有 的 方 
便 与 高 效 。 同 时 ,Docker 借 助 强大 的 镜像 技术 ， 让 应 用 的 分 发 、 部 署 
与 管理 变 得 史无前例 的 便捷 。 然 而 ，Docker 毕 况 是 一 项 较为 新 颖 的 技 
术 ,在 Docker 的 世界 中 ， 用 户 并 非 一 劳 永 逸 ， 其 中 最 为 业界 所 诉 病 的 
便 是 Docker 的 网 络 问题 。 


毋庸 置疑 ， 对 于 Docker 管 理 者 和 开发 者 而 言 ， 如何 有 效 、 高 效 地 
管理 Docker 容 器 之 间 的 交互 以 及 Docker 容 器 的 网 络 一 直 是 一 个 巨大 
的 挑战 。 目 前， 云 计 算 领 域 中 ， 绝 大 多 数 系统 都 采取 分 布 式 技术 来 设 
计 并 实现 。 然 而 ,在 原生 态 的 Docker 世 界 中 ，Docker 的 网 络 却 不 具 
备 跨 宿主 机 的 能 力 ， 这 也 或 多 或 少 制约 着 Docker 在 云 计算 领域 的 高 速 
发 展 。 


Docker 网 络 问题 的 解决 势 在 必 行 ， 面 对 不 同 的 应 用 场景 ， 不 少 IT 
企业 都 开发 了 各 自 的 新 产品 来 帮助 完善 Docker 的 网 络 。 这 些 企业 中 不 


乏 像 Google 一 样 的 互联 网 翘楚 ， 同 时 也 有 不 少 初 创 企 业 率 先 出 击 ， 在 
最 前 沿 不 懈 探 索 。 这 些 新 产品 包括 : Google 推 出 的 容 莫 管理 和 编排 工 
具 Kubernetes , Zett.io 公 司 开发 的 通过 虚拟 网 络 连接 跨 条 主机 容 善 
的 工具 Weave , CoreOS 团 队 针 对 Kubernetes 设 计 的 网 络 履 盖 工 具 
Flannel , Docker 官 方 的 工程 师 ]ér6me Petazzoni 自 己 设计 的 SDN 
网 络 解决 方案 Pipework， 以 及 SocketPlane 项 目 等 。 


对 于 Docker 管 理 者 与 开发 者 而 言 , 虽然 Docker 的 跨 和 宿主 机 通信 
能 力 暂时 不 够 完善 ,但 了 解 Docker 自 身 的 网 络 架 构 也 是 很 有 必要 的 。 
只 有 深入 了 解 Docker 自 身 的 网 络 设计 与 实现 ,才能 清楚 其 次 端 ,从 而 
扩展 Docker 的 跨 宿主 机 能 力 。 


Docker 自 身 的 网 络 主要 包含 两 部 分 : Docker Daemon 的 网 络 
配置 、Docker 容 妖 的 网 络 配置 。 本 章 主要 从 源码 的 角度 ， 分析 
Docker Daemon 在 启动 过 程 中 ， 为 Docker 配 置 的 网 络 环 境 ,内容 
安排 如 下 : 


1) Docker Daemon 网 络 配 置 。 
2) 运行 Docker Daemon 网络 初 始 化 任务 。 


3) 创建 Docker 网 桥 。 


6.2 Docker Daemon 网 络 介绍 


在 Docker 环 境 中 ，Docker 容 器 的 网 络 能 力 一 直 备 受 关心 。 对 一 
个 Docker 容 器 而 言 , 它 可 以 独 享 内 部 的 网 络 栈 ， 并 与 其 他 容 右 分 处 隔 
离 的 网 络 环 境 。 然 而 作为 DockerDaemon 创 建 的 容 疾 ， 容 莫 与 宿主 
机 之 外 建立 通信 时 ， 仍然 无 可 避免 地 通过 宿主 机 物理 网 卡 或 者 虚拟 机 
的 eth0 虚 拟 网 卡 。 既 然 如 此 ,那么 如 何 构 建 Docker 容 兹 与 宿主 机 之 
间 的 网 络 拓 扑 ， 将 是 一 个 学 习 Docker 网 络 时 必须 理解 的 关键 点 。 


和 一 台 没有 安装 Docker 的 宿主 机 上 ， 网 络 环境 很 有 可 能 平淡 无 
奇 。 然 而 , 当 用 户 开 始 安装 并 启动 Docker 时 ， 一 切 发 生 了 变化 。 而 
Docker 管 理 员 完 全 有 权限 在 局 动 Docker 时 配置 Docker Daemon 的 
网 络 模式 。 


关于 Docker 的 网 络 模式 ， 大 家 最 熟知 的 应 该 就 是 “桥接 "模式 ， 
也 被 称 为 bridge 模 式 。 在 桥接 模式 下 ，Docker 的 网 络 环境 折 #N 包 
括 Docker Daemon 网 络 环境 和 Docker Container 网 络 环境 ) 如 图 
6-1 所 示 。 






docker0 (bridge) 


ipv4d ip forward 


Host 








6-1 Docker 网 络 桥 接 模式 示意 图 


然而 ,“ 桥 接 " 模 式 是 Docker 网 络 模式 中 最 为 常用 的 模式 。 除 此 
之 外 ，Docker 还 为 用 户 提供 了 更 多 的 可 选项 ， 本 章 余下 部 分 将 进行 深 
入 分 析 。 


6.3 Docker Daemon 网络 配 置 接口 


Docker Daemon 每 次 启动 的 过 程 中 ， 都 会 初始 化 自身 的 网 络 环 
境 。 初 始 化 后 的 网 络 环境 最 终 为 Docker 容 器 提供 网 络 通信 服务 。 为 了 
实现 Docker Daemon 网 络 的 初始 化 ,Docker 管 理 员 可 以 在 局 动 
Docker Daemon 时 ,通过 参数 的 形式 配置 Docker 的 网 络 环境 。 配 置 
参数 可 以 通过 运行 docker 二 进 制 可 执行 文件 来 完成 ， 即 通过 运行 
docker-d 并 添加 其 他 与 网 络 相 关 的 flag 参 数 来 完成 。 


其 中 ， 涉 及 的 flag 参 数 有 Enablelptables、EnablelpForward、 
Bridgelface、BridgelP 以 及 InterContainerCommunication。 这 5 
个 与 网 络 相关 的 flag 参 数 的 定义 位 
于 ./dockerdockervdaemon/config.go#L49-L53 ,具体 源码 如 
这 


flag.BoolVar(&config.EnableIptables, []string{"#iptables", "-iptables"}, true, 
"Enable Docker's addition of iptables rules") 
flag.BoolVar(&config.EnableIpForward, []string{"#ip-forward", "-ip-forward"}, 
true, "Enable net.ipv4.ip forward") 

flag.StringVar(&config.BridgeIPp, []string{"#bip", "-bip"}, "", "Use this CIDR 
notation address for the network bridge's IP, not compatible with -b") 
flag.StringVar(&config.Bridgelface, []string{"b", "-bridge"}, "", "Attach 


containers to a pre-existing network bridge\nuse 'none' to disable container 
networking") 

flag.BoolVar(&config.InterContainerCommunication, []string{"#icc", "-icc"}, true, 
"Enable inter-container communication") 


以 下 介绍 这 5 个 flag 参 数 的 作用 : 


:Enablelptables : 确保 Docker Daemon 启 动 时 ,能 对 宿主 机 上 
的 iptables 规 则 进行 修改 。 


:EnablelpForward : 确保 net.ipv4.ip_forward 功 能 开启 ， 使 得 
宿主 机 在 多 网 络 接口 模式 下 ， 数据 包 可 以 在 网 络 接 口 之 间 转 发 。 


:BridgelP : Docker Daemon 为 网 络 环境 中 的 网 桥 配 置 的 CIDR 
网 络 地 址 。 


:Bridgelface : 为 Docker 网 络 环境 指定 具体 的 通信 网 桥 ， 若 
Bridgelface 的 值 为 none， 则 说 明 不 需要 为 Docker 容 大 创建 网 桥 服 
务 ， 关 闭 Docker 容 器 的 网 络 能 力 。 


:|nterContainerCommunication : 确保 Docker 容 器 之 间 可 以 
完成 通信 , 通过 防火 墙 完成 
除 DockerDaemon 会 使 用 到 的 5 个 flag 参 数 之 外 , Docker 在 创建 


网 络 环境 时 ， 还 使 用 一 个 DefaultIP 变 量 ， 如 下 所 示 : 


opts.IPVar(&config.DefaultIp, []string{"#ip", "-ip"}, "0.0.0.0", "Default IP 
address to use when binding container ports") 


该 变量 的 作用 是 : 绑 定 Docker 容 兹 的 端口 与 答 主 机 上 的 某 一 个 端 
口 时 ,将 Defaultip 作 为 默认 使 用 的 答 主 机 iP 地址。 


具备 以 上 Docker Daemon 的 网 络 背 景 知识 之 后 ， 我们 来 分 析 如 
何 通 过 docker 二 进 制 文件 启动 Docker Dameon 并 配置 相应 的 网 络 环 
境 。Docker Daemon 的 网 络 环境 和 两 个 fag 参 数 相关 性 最 大 ， 分 别 
为 BridgelP 和 Bridgelface。 举 例 说 明 如 表 6-1 所 示 。 


表 6-1 Docker Daemon 启动 命 令 表 


启动 Docker Daemon 命令 作用 分 析 
docker -d 启动 Docker Daemon， 使 用 默认 网 桥 docker0， 不 指定 CIDR 网 络 地 址 
docker -d -b="xxx" 启动 Docker Daemon， 使 用 网 桥 xxx， 不 指定 CIDR 网 络 地 址 
docker -d --bip="172.17.42.1" 启动 Docker Daemon， 使 用 默认 网 桥 docker0， 使 用 指定 CIDR 网 络 


地 址 172.17.42.1 
docker -d --bridge="xxx" --bip="10.0.42.1" 报错 ， 出 现 兼容 性 问题 ， 不 能 同时 指定 BridgeIP 和 Bridgelface 
docker -d --bridge="none" 启动 Docker Daemon， 不 创建 Docker 网 络 环境 





深入 理解 Bridgelface 与 BridgelP， 并 熟练 使 用 相应 的 flag 参 数 ， 
就 能 做 到 配置 Docker Daemon 的 网 络 环境 。 需 要 特别 注意 的 是 ， 
Docker Daemon 的 网 络 与 Docker 容 兹 的 网 络 存在 很 大 的 区 别 。 
Docker Daemon 为 Docker 容 器 创建 网 络 的 大 环境 ,Docker 容 器 的 
网 络 需 要 Docker Daemon 的 网 络 提供 支持 ， 但 不 唯一 。 举 一 个 形象 
的 例子 ， Docker Daemon 可 以 创建 docker0 网 桥 ， 为 之 后 Docker 容 
妖 的 桥接 模式 提供 支持 ; 然而 在 桥接 模式 下 ，Docker 容 希 可 以 局 用 桥 
接 ， 转 而 根据 用 户 需求 创建 自身 网 络 。 其 中 Docker 容 希 的 网 络 可 以 是 
桥接 模式 的 网 络 ， 同 时 也 可 以 直接 共享 答 主 机 的 网 络 设备 ， 另 外 还 有 
其 他 模式 。 关 于 Docker 容 希 的 网 络 ， 将 在 第 7 章 进行 详细 介绍 。 


6.4 Docker Daemon 网 络 初 始 化 


正如 上 一 节 所 言 ，Docker 管 理 员 可 以 通过 与 网 络 相关 的 flag 参 数 
Bridgelface 与 BridgelP ,来 为 Docker Daemon 创 建 网 络 环境 。 最 
简单 的 ，Docker 管 理 员 通过 执行 "dockerd" 就 已 经 完成 Docker 


Daemon 的 运行 。 


Docker Daemon 网络 初始 化 流程 如 图 6-2 所 示 。 


他]ag.Parse) 


Config. Bridge]P 
config, Bridgelface (defaul 


config. DisableNetwork=true 


job := eng, Job( “init networkdriver” 


job. Setenv() 


job. Runt) 
(InitDriver) 





图 6-2 Docker Daemon 网 络 初 始 化 流程 图 


总 体 而 言 , Docker Daemon 网 络 的 初始 化 流程 主要 是 根据 解析 
flag 参 数 来 决定 到 底 建 立 哪 种 类 型 的 网 络 环境 。 从 流程 图 中 可 知 ， 
Docker Daemon 创建 网 络 环境 时 有 两 个 分 支 ， 不 难 发 现 分 支 代表 的 
分 别 是 : 为 Docker 创 建 一 个 网 络 驱动 ， 以 及 对 Docker 的 网 络 不 做 任 
何 操作 。 


下 面 参照 Docker Daemon 网 络 初始 化 流程 图 具体 分 析 实 现 步 


6.4.1 局 动 Docker Daemon 传 递 flag 参 数 


用 户 希 望 感受 到 Docker 带 来 的 便利 ,首先 必须 要 有 一 个 运行 着 的 
Docker Daemon。 因 此 ， 用 户 第 一 步 要 完成 的 就 是 启动 Docker 
Daemon。 用 户 可 以 通过 docker 可 执行 文件 来 启动 Docker 
Daemon， 并 在 命令 行 中 选择 性 地 传 入 所 需要 的 flag 参 数 。 


6.4.2 解析 网 络 flag 参 数 


Docker Daemon 的 启动 前 期 ，Docker 使 用 flag 包 对 命令 行 中 的 
flag 参 数 进 行 解 析 。 其 中 和 Docker Daemon 网 络 配 置 相关 的 flag 参 
数 有 五 个 ,分 别 是 : Enablelptables、EnablelpForward、 
BridgelP、Bridgelface 以 及 InterContanierCommunication ,各 
个 flag 参 数 的 作用 本 章 已 有 介绍 。 


6.4.3” 预 处 理 flag 参 数 


解析 完 与 Docker Daemon 网 络 相 关 的 flag 参 数 之 后 ，Docker 仍 
然 需要 对 这 些 参数 的 值 进 行 预 处 理 。 预 处 理 与 网 络 配置 相关 的 flag 参 
数 信息 ， 包 括 检测 配置 信息 的 兼容 性 ， 以 及 判断 是 否 创建 Docker 网 络 
环境 。 


首先 ，Docker 需 要 检验 flag 参 数 中 是 人 否 会 出 现 彼此 不 兼容 的 信 
息 ， 源码 位 于 ./dockervdockervdaemon/daemon.go##L679- 
L685 , 如 下 所 示 : 


// Check for mutually incompatible config options 
if config.BridgeIface != "" &é& config,BridgeIP != "" { 
return nil, fmt.Errorf("You specified -b & --bip, mutually exclusive 
options. Please specify only one.") 
if !config.EnableIptables && !config,InterContainerCommunication { 
return nil, fmt.Errorf("You specified --iptables=false with -- 


icc=false. ICC uses iptables to function. Please set --icc or --iptables to 
true.") 


flag 参 数 的 兼容 信息 主要 有 了 两 种 。 


第 一 种 ，BridgelP 和 Bridgelface 配 置信 息 的 兼容 性 。 具 体 表现 
为 用 户 启动 Docker Daemon 时 ， 若 同时 指定 了 BridgelP 和 
Bridglface 的 值 ， 则 出 现 兼 容 问题 。 原 因 在 于 这 两 者 属于 互 斥 对 ， 换 
言 之 ， 若 用 户 指定 了 新 建 网 桥 的 设备 名 ， 那 么 该 网 桥 已 经 存在 ， 无 须 


指定 网 桥 的 IP 地 址 BridgelP ; 若 用 户 指 定 了 新 建 网 桥 的 网 络 IP 地 址 
BridgelP， 那么 该 网 桥 肯 定 还 没有 新 建成 功 ， 则 Docker Daemon 在 
新 建 网 桥 时 使 用 默认 网 桥 名 docker0 ， 无 须 在 另行 指定 网 桥 的 设备 
名 5 


第 二 种 ,Enablelptables 和 InterContainerCommunication 配 
置信 息 的 兼容 性 。 具 体 表现 为 不 能 同时 指定 这 两 个 fag 参 数 为 false。 
原因 很 简单 ， 若 指定 InterContainerCommunication 为 false ， 则 说 
明 Docker Daemon 不 允许 创建 的 Docker 容 右 之 间 进 行 互相 通信 。 
但 是 为 了 达到 以 上 目 的 ,Docker 正 是 使 用 iptables 防 火 墙 的 过 滤 规 
则 。 因 此 ,再 次 设 定 Enablelptables 为 false ， 关闭 iptables 的 使 
用 , 即 出 现 了 自 相 矛盾 的 结 


检验 完 系统 配置 信息 的 兼容 性 问题 ，Docker Daemon 接 着 会 判 

煌 是 否 需 要 为 Docker Daemon 配置 网 络 环境 。 判 断 的 依据 为 
Bridgelface 的 值 是 人 否 与 DisableNetworkBridge 的 值 相等 ， 
DisableNetworkBridge 
在 ./dockerdockerdaemon/config.go#L13 中 被 定义 为 Const 常 
量 ， 值 为 字符 串 none。 因 此 , 若 Bridgelface 为 none , 则 
DisableNetwork 为 true , 最终 Docker Daemon 不 会 创建 网 络 环 
境 ; 若 Bridgelface 不 为 none, 则 DisableNetwork 为 false， 最终 
Docker Daemon 需 要 创建 网 络 环境 ( 桥接 模式 ) 


6.4.4 确定 Docker 网 络 模式 


Docker 网 络 模式 由 配置 信息 DisableNetwork 决 定 。 由 于 在 上 一 
节 Docker Daemon 已 经 得 出 DisableNetwork 的 值 ， 故 本 节 可 以 确 
定 Docker 网 络 模式 。 这 部 分 的 源码 实现 位 
于 ./docker/docker/daemon/daemon.go#L792-L805 , 如 下 所 


小: 


if !config.DisableNetwork { 
job := eng.Job("init networkdriver") 
job.SetenvBool ("EnableIptables", config.EnableIptables) 
job.SetenvBool("InterContainerCommunication", 
config.InterContainerCommunication) 
job.SetenvBool ("EnableIlpForward", config.EnableIlpForward) 
job.Setenv("Bridgelface", config.BridgeIlface) 
job.Setenv("BridgeIP", config.BridgelIP) 
job.Setenv("DefaultBindingIP", config.DefaultIp.String()) 
if err := job.Run(); err != nil { 
return nil, err 
} 


和 铬 DisableNetwork 为 false， 则 说 明 需 要 为 Docker Daemon 创 
建 网 络 环境 ,具体 的 模式 为 网 桥 模 式 。 创 建 Docker Daemon 网 络 环 
境 的 步 又 为 : 


1) 创建 名 为 init_networkdriver 的 Job。 


2) 为 job 配置 环境 变量 ,配置 的 环境 变量 有 Enablelptables、 


InterContainerCommunication、EnablelpForward、 


Bridgelface、BridgelP 以 及 DefaultBindinglP。 
3) 触发 执行 job。 


运行 init_network 实 际 完成 的 工作 是 创建 Docker 网 桥 ， 这 部 分 
内 容 将 会 在 下 一 节 详 细 分 析 。 


若 DisableNetwork 为 true。 则 说 明 不 需要 为 Docker Daemon 
创建 网 络 环境 ， 网 络 模式 属于 none 模 式 。 


以 上 便 是 Docker Daemon 网 络 初始 化 的 所 有 流程 。 


6.5 创建 Docker 网 桥 


Docker 的 网 络 往往 是 Docker 开 发 者 最 常 提 起 的 话题 。 而 Docker 
网 络 中 最 常 使 用 的 模式 为 桥接 模式 。 本 节 将 详细 分 析 Docker 网 桥 的 创 
建 流程 。 


Docker 网 桥 的 创建 通过 init_network 这 个 Job 的 运行 来 完成 。 
init_network 的 实现 为 InitDriver 贸 数 ,位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L 


79 , InitDriver 贸 数 的 运行 流程 如 图 6-3 所 示 。 
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6.5.1 提取 环境 变量 


在 InitDriven 溪 数 的 实现 过 程 中 ，Docker 首 先 提取 
init_networkdriver 这 个 J]ob 的 环境 变量 。 这 样 的 环境 变量 共有 6 个 ， 
各 自 的 作用 在 上 文 已 经 详细 说 明 。 具 体 的 实现 源码 如 下 : 

var ( 


network *net.IPNet 


enableIPTables = job.GetenvBool ("EnableIptables") icc = 
job.GetenvBool("InterContainerCommunication") ipForward = 
job.GetenvBool ("EnableIpForward") bridgeIP = job.Getenv("BridgeIP") ) 


if defaultIP := job.Getenv("DefaultBindingIP"); defaultIP != "" { 
defaultBindingIP = net.ParseIP(defauLtIP) } 


bridgeIface = job.Getenv("BridgeIface'") 


6.5.2 确定 Docker 网 桥 设备 名 


提取 job 的 环境 变量 之 后 ,Docker 随 即 确定 最 终 使 用 网 桥 设备 的 
名 称 。 为 此 , Docker 首 先 创 建 了 一 个 名 为 usingDefaultBridge 的 
bool 变 量 ， 含义 为 是 否 使 用 默认 的 网 桥 设备 ， 上 默认 值 为 false。 接 着 ， 
若 环 境 变 量 中 bridgelface 的 值 为 空 ， 则 说 明 用 户 启动 Docker 时 ，, 没 
有 指定 特定 的 网 桥 设 备 名 ， 因 此 Docker 首 先 将 usingDefaultBridge 
荀 为 true ,然后 使 用 默认 的 网 桥 设 备 名 DefaultNetworkBridge 赋 值 
于 bridgelface , 即 docker0 ; 若 bridgelface 的 值 不 为 空 ， 则 判断 条 
件 不 成 立 ， 继 续 往 下 执行 。 这 部 分 的 源码 实现 为 : 


usingDefaultBridge := false if bridgeIface == "" { 


usingDefaultBridge = true bridgeIface = DefaultNetworkBridge } 


6.5.3 查找 bridgelface 网 桥 设 备 


确定 Docker 网 桥 设备 名 bridgelface 之 后 ，Docker 首 先 通过 
bridgelface 设 备 名 在 宿主 机 上 查找 该 设备 是 人 否 真 实 存在 。 若 存在 ， 
则 返回 该 网 桥 设 备 的 IP 地 址 ， 若 不 存在 ， 则 返回 nil。 实 现 源 码 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L 
99 ,如 下 所 示 : 


addr, err := networkdriver.GetIfaceAddr(bridgeIface) 


GetlfaceAddr 的 实现 位 
于 ./docker/docker/daemon/networkdriver/utils.go， 实现 步 又 
为 : 首先 通过 Golang 中 net 包 的 InterfaceByName 方 法 获取 名 为 
bridgelface 的 网 桥 设 备 ， 会 得 出 以 下 结 


: 若 名 为 bridgelface 的 网 桥 设 备 不 存在 ,直接 返回 错误 


- 若 名 为 bridgelface 的 网 桥 设备 存在 ,返回 该 网 桥 设备 的 IP 地 
址 。 


需要 强调 的 是 : GetlfaceAddn 六 数 返 回 错误 ， 说 明 当 前 答 主 机 
上 不 存在 名 为 bridgelface 的 网 桥 设 备 。 而 这 样 的 结果 会 有 两 种 不 同 
的 情况 : 第 一 ， 用 户 指定 了 bridgelface , 那么 usingDefaultBridge 


为 false， 而 该 bridgelface 网 桥 设 备 在 和 宿主 机 上 不 存在 ; 第 二 ， 用 户 
没有 指定 bridgelface , 那么 usingDefaultBridge 为 true ， 
bridgelface 名 为 docker0 , 而 docker0 网 桥 在 宿主 机 上 也 不 存在 。 


当然 ， 若 GetlfaceAddr 纹 数 返回 的 是 一 个 IP 地 址 ， 则 说 明 当前 宿 
主机 上 存在 名 为 bridgelface 的 网 桥 设备 。 这 样 的 结果 同样 会 有 两 种 
不 同 的 情况 : 第 一 ,用户 指定 了 bridgelface , 那么 
usingDefaultBridge 为 false , 而 该 bridgelface 网 桥 设备 在 宿主 机 
上 已 经 存在 ; 第 二 ， 用户 没有 指定 bridgelface , 那么 
usingDefaultBridge 为 true , bridgelface 名 为 docker0 ,而 
docker0 网 桥 在 宿主 机 上 也 已 经 存在 。 第 二 种 情况 一 般 是 : 用 户 在 往 
主机 上 第 一 次 启动 Docker Daemon 时 ， 创 建 了 默认 网 桥 设备 
docker0 , 而 后 docker0 网 桥 设备 一 直 存 在 于 宿主 机 上 ， 故 之 后 在 不 
指定 网 桥 设备 的 情况 下 ， 重启 Docker Daemon , 会 出 现 docker0 已 
经 存在 的 情况 。 


以 下 两 节 将 分 别 从 bridgelfaceb 已 创建 与 bridgelface 未 创建 两 种 
不 同 的 情况 进行 深入 分 析 。 


6.5.4 bridgelface 已 创建 


Docker Daemon 所 在 宿主 机 上 bridgelface 的 网 桥 设 备 存在 
时 ，Docker Daemon 仍 然 需 要 验证 用 户 在 配置 信息 中 是 否 为 网 桥 设 
备 指定 了 IP 地 址 。 


用 户 启动 Docker Daemon 时 ， 假 如 没有 指定 bridgelP 参 数 信 
息 , 则 Docker Daemon 使 用 名 为 bridgelface 的 原 有 的 IP 地 址 。 


当 用 户 指定 了 bridgelP 参 数 信息 时 ， 则 需要 验证 : 指定 的 
bridgelP 参 数 信 息 与 bridgelface 网 桥 设 备 原 有 的 IP 地 址 信息 是 否 匹 
配 。 若 两 者 匹配 ， 则 验证 通过 ， 继续 往 下 执行 ; 若 两 者 不 匹配 ， 则 验 
证 不 通过 ， 抛 出 错误 ， 显 示 “bridgelP 与 已 有 网 桥 配置 信息 不 匹配 ”。 
该 部 分 内 容 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L 
119-L129 , 源码 如 下 : 


network = addr. (*net.IPNet) 
// validate that the bridge ip matches the ip specified by BridgeIP 
if bridgeIP != "" { 
bip, ，err := net.ParseCIDR(bridgeIP) 
if err != nil { 
return job.Error(err) 


} 
if !network.IP.EquaL(bip) { 
return job.Errorf("bridge ip (%s) does not match existing bridge 


configuration %s", network.IP, bip) 


} 


6.5.5 bridgelface 未 创建 


Docker Daemon 所 在 宿主 机 上 bridgelface 的 网 桥 设备 未 创建 
时 ， 上 文 已 经 介绍 将 存在 两 种 情况 : 


用户 指 定 的 bridgelface 未 创建 。 
:用 户 未 指定 bridgelface , 而 docker0 暂 未 创建 。 


当 用 户 指定 的 bridgelface 不 存在 于 宿主 机 时 ， 即 没有 使 用 
Docker 的 默认 网 桥 设 备 名 docker0 ，DockerJEb 日 志 信 息 “ 指 定 网 桥 
设备 未 找到 ”, 并 返回 网 桥 未 找到 的 错误 信息 。 源 码 实 现 如 下 : 


if !usingDefauLtBridge { 
job.Logf ("bridge not found: %s"，bridgeIface) 
return job.Error(err) 


} 


当 使 用 默认 网 桥 设备 名 ， 而 docker0 网 桥 设备 还 未 创建 时 ， 
Docker Daemon 则 立即 实现 创建 网 桥 的 操作 ， 并 返回 该 docker0 网 
桥 设备 的 IP 地 址 。 代 码 如 下 : 


// If the iface is not found, try to create it 

job.Logf("creating new bridge for %s", bridgeIlface) 

if err := createBridge(bridgeIP); err != nil { 
return job.Error(err) 


job.Logf ("getting iface addr") 
addr, err = networkdriver.GetIfaceAddr(bridgeIface) 
if err != nil { 

return job.Error(err) 


} 
network = addr. (*net.IPNet) 


创建 Docker Daemon 网 桥 设 备 docker0 的 实现 ， 全 部 由 
createBridge( bridgelP) 来 实现 ,createBridge 的 实现 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L 
245。createBridge 曙 数 实现 步骤 如 下 : 


1) 确定 网 桥 设 备 docker0 的 IP 地 址 。 


2) 通过 createBridgelface 上 加 数 创建 docker0 网 桥 设备 ， 并 为 网 
桥 设备 分 配 随机 的 MAC 地 址 。 


3) 将 第 一 步 中 已 经 确定 的 IP 地 址 ,添加 给 新 创建 的 docker0 网 
桥 设备 。 


4) 启动 docker0 网 桥 设 备 。 
下 面 详细 分 析 4 个 步 又 的 具体 实现 。 


第 一 步 ，Docker Daemon 确 定 docker0 的 iP 地址 ,实现 方式 为 
判断 用 户 是 否 为 网 桥 设 备 指定 bridgelP。 若 用 户 未 指定 bridgelP，, 则 
从 Docker 预 先 准 备 的 IP 网 段 列表 addrs 中 查找 合适 的 网 段 。 具 体 的 源 
码 实 现 位 
于 ./docker/docker/daemon/networkdriver/bridge/driver.go#L 
257-L278 , 如 下 所 示 : 


if len(bridgeIP) != 0 { 
 ，_, err := net.ParseCIDR(bridgeIP) 
if err != nil { 
return err 


} 
ifaceAddr = bridgeIP 


} else { 
for , addr := range addrs { 
_,， dockerNetwork, err := net,ParseCIDR(addr) 
if err != nil { 
return err 
} 
if err := networkdriver.CheckNameserverOverlaps (nameservers, 
dockerNetwork); err == nil { 
if err := networkdriver.CheckRouteOverlaps(dockerNetwork); err == 
nil { 
ifaceAddr = addr 
break 
} else { 
log.Debugf("%s %s", addr, err) 
} 
} 
} 


其 中 ，Docker Daemon 为 网 桥 设 备 准备 的 候选 网 段 地 址 addrs 
为 : 


addrs = []stringt{ 
"172.17.42.1/16", // Don't use 172.16.0.0/16, it conflicts with EC2 DNS 

172.16.0.23 

"10.0.42.1/16", // Don't even try using the entire /8, that's too intrusive 

"10.1.42.1/16", 

"10.42.42.1/16", 

"172.16.42.1/24", 

"172.16.43.1/24", 

"172.16.44.1/24", 

"10.0.42.1/24", 

"10.0.43.1/24", 

"192.168.42.1/24", 

"192.168 .43 .1/24"， 

"192 .168 .44.1/24"， 


通过 执行 以 上 流程 ，Docker Daemon 可 以 确定 一 个 可 用 的 IP 网 
段 地 址 ,为 ifaceAddr ; 若 仍 然 未 匹配 合适 的 网 段 地 址 ， 


DockerDaemon 返 回 错误 有 日志， 表明 没有 合适 的 IP 地 址 赋予 
docker0 网 桥 设备 。 


第 二 步 ，DockerDaemon 通 过 createBridgelface 组 数 创 建 
docker0 网 桥 设备 。createBridgelface 上 男 数 的 源码 实现 如 下 : 


func createBridgeIface(name string) error { 
kv, err := kerneL,GetKkerneLyersion() 
// only set the bridge's mac address if the kernel version is > 3.3 
// before that it was not Supported 
setBridgeMacAddr := err == niL &é& (kv.Kernel >= 3 && kv.Major >= 3) 
log.Debugf ("setting bridge mac address = %v", setBridgeMacAddr) 
return netlink.CreateBridge(name, setBridgeMacAddr) 


以 上 代码 通过 答 主 机 Linux 内 核 信 息 , 确定 答 主 机 内 核 版 本 是 
支持 设 定 网 桥 设备 的 MAC 地 址 。 若 Linux 内 核 版 本 大 于 3.3， 则 支持 配 
置 MAC 地 址 ,否则 不 支持 。 而 Docker 在 不 低 于 3.8 的 内 核 版 本 上 才能 
稳定 运行 ， 故 可 以 认为 内 核 支持 配置 MAC 地 址 。 最 后 通过 netlink 的 
CreateBridge 男 数 实现 创建 docker0 网 桥 。 


Netlink 是 Linux 中 一 种 较为 特殊 的 Socket 通 信 方 式 ， 提 供 了 用 户 
应 用 间 和 内 核 进 行 双向 数据 传输 的 途径 。 在 这 种 模式 下 ， 用 户 态 可 以 
使 用 标准 的 Socket APl 来 使 用 netlink 强 大 的 功能 ， 而 内 核 态 需要 使 
用 专门 的 内 核 API 才 能 使 用 netlink。 


libcontainer 的 netlink 包 中 的 CreateBridge 实 现 了 创建 实际 的 
网 桥 设 备 ， 具 体 使 用 系统 调用 的 代码 如 下 : 


syscall.Syscall(syscall.SYS IOCTL, uintptr(s), SIOC BRADDBR, 
uintptr(unsafe.Pointer(nameBytePtr))) 


创建 完 网 桥 设 备 之 后 ， 为 docker0 网 桥 设 备 配 置 MAC 地 址 ， 实 现 
级 数 为 setBridge-MacAddress。 


第 三 步 为 创建 的 docker0 网 桥 设备 绑 定 I|P 地 址 。 上 一 步 仅 完 成 了 
创建 名 为 docker0 的 网 桥 设 备 ， 之 后 仍 需 要 为 docker0 网 桥 设备 绑 定 
IP 地 址 。 具 体 源码 实现 为 : 


if netlink.NetworkLinkAddIp(iface, ipAddr, ipNet); err != nil { 
return fmt.Errorf("Unable to add private network: %s", err) 


NetworkLinkAddIlP 的 实现 同样 位 于 libcontainer 中 的 netlink 
包 ，, 主要 的 功能 为 : 通过 netlink 机 制 为 一 个 网 络 接口 设备 绑 定 一 个 IP 
地 址 。 


第 四 步 是 启动 docker0 网 桥 设备 。 有 具体 实现 代码 如 下 : 


if err := netlink.NetworkLinkUp(iface); err != nil { 
return fmt.Errorf("Unable to start network bridge: %s", err) 


NetworkLinkUp 的 实现 同样 位 于 libcontainer 中 的 netlink 包 ， 
功能 为 启动 docker0 网 桥 设备 。 


至 此 ， docker0 网 桥 历经 确定 IP、 创 建 、 绑 定 IP、 启 动 四 个 环 
节 ，createBridge 关 于 docker0 网 桥 设 备 的 工作 全 部 完成 。 


6.5.6 ” 猴 取 网 桥 设 备 的 网 络 地 址 


创建 完 网 桥 设备 之 后 ,网 桥 设 备 必 然 会 存在 一 个 网 络 地 址 。 网 桥 
网 络 地 址 的 作用 为 : Docker Daemon 在 创建 Docker 容 器 时 ,使 用 
该 网 络 地 址 为 Docker 容 器 分 配 IP 地 址 。Docker 使 用 源码 
network=addr.( *net.lIPNet) 获取 网 桥 设 备 的 网 络 地 址 。 


6.5.7 ”配置 Docker Daemon 的 iptables 


创建 完 网 桥 之 后 ，Docker Daemon 为 容 希 以 及 得 主机 配置 
iptables， 包 括 为 容 怖 之 间 所 需要 的 link 操 作 提 供 支 持 ， 为 特 主 机 上 
所 有 的 对 外 对 内 流量 制定 传输 规则 等 。 这 部 分 详情 可 参见 第 4 章 ， 源 
码 实现 位 
于 ./docker/daemon/networkdriver/bridge/driver/driver.go#L1 
33 ,如 下 所 示 : 


// Configure iptables for Link support if enabLeIPTabtLes { 
if err := setupIPTables(addr, icc); err != nil { 


return job.Error(err) } 


// We can always try removing the iptables if err := 
iptables.RemoveExistingChain("DOCKER"); err != nil { 


return job.Error(err) } 
if enableIPTables { 
chain, err := iptables.NewChain("DOCKER", bridgeIlface) if err != nil { 


return job.Error(err) } 


portmapper.SetIptablesChain(chain) } 


6.5.8” 配 首 网 络 设备 间 数 据 报 转发 功能 


默认 情况 下 ，Linux 操 作 系 统 上 的 数据 包 转 发 功能 是 禁止 的 。 数 
据 包 转发 就 是 当 宿 主机 存在 多 个 网 络 设备 时 ， 如果 其 中 一 个 接收 到 数 
据 包 ， 并 将 其 转发 给 另外 的 网 络 设备 。Docker Daemon 通 过 修 
改 /proc/sys/net/ipv4/ip_forward 的 值 ,将 其 置 为 1， 则 可 以 保证 系 
统 内 数据 包 可 以 实现 转发 功能 ， 代 码 如 下 : 


if ipForward { 
// Enable IPv4 forwarding 


if err := ioutil.WriteFile("/proc/sys/net/ipv4/ip forward", [lbyte{'1', 
'\n'}, 0644); err != nil { 


job.Logf ("WARNING: unable to enable IPv4 forwarding: %s\n", err) 


6.5.9 注册 网 络 Handler 


创建 Docker Daemon 网 络 环境 的 最 后 一 个 步骤 是 : 注册 4 个 与 
网 络 相关 的 Handler。 这 4 个 处 理 方 法 分 别 是 allocate interface、 
release interface、allocate_port 和 link, 作用 分 别 是 为 Docker 容 
闫 分 配 IP 网 络 地 址 ， 释 放 Docker 容 背 网 络 设备 ， 为 Docker 容 背 分 配 
端口 资源， 以 及 在 Docker 容 器 之 间 执 行 link 操 作 。 


至 此 , Docker Daemon 的 网 络 环境 初始 化 工作 全 部 完成 。 


6.6 总 结 


在 工业 界 ，Docker 的 网 络 问题 备 受 关注 。Docker 的 容器 技术 以 
及 镜像 技术 , 已 经 给 Docker 实 践 者 带 来 了 诸多 效益 。 然 而 Docker 网 
络 的 发 展 依然 具 有 很 大 的 潜力 ， 依 然 值得 大 家 不 断 探索 并 推动 其 发 
展 。 

Docker 的 网 络 环境 可 以 分 为 Docker Daemon 网络 和 Docker 


Container 网 络 。 本 章 从 Docker Daemon 的 网 络 入 手 ， 分 析 了 大 家 
熟知 的 Docker 桥 接 模式 。 


第 7 童 ”Docker 容 器 网 络 
7.1 引言 


如 今 ，Docker 技 术 风 靡 全 球 , 大 家 在 尝试 以 及 玩 转 Docker 的 同 
时 , 肯定 离 不 开 一 个 概念 ， 那 就 是 “容器 "或 者 “Container”"。 那 么 我 
们 首先 从 原理 的 角度 一 规 “ 容 器 ”或 者 “Container” 的 究竟 。 


第 一 次 接触 Docker 时 ， 大 家 肯定 会 深 深 感受 到 : 在 Docker 容 颖 
内 部 运行 应 用 程序 竟 是 如 此 方便 。 第 一 ， 应 用 程序 在 Docker 容 硕 内 部 
的 部 署 与 运行 非常 便捷 ,只 要 有 Dockerfile， 应 用 一 键 式 的 部 署 绝对 
不 是 天 方 夜 谭 ; 第 二 ，Docker 容 妖 内 运行 的 应 用 程序 还 可 以 受到 资源 
的 控制 与 隔离 ， 大 大 满足 云 计算 时 代 应 用 的 要 求 。 


考 庸 置疑, Docker 的 一 些 特性 ,的确 握 弃 了 传统 情况 下 开发 模式 
的 不 少 浆 端 。 然 而 ， 这 强大 的 功能 背后 到 底 是 何等 技术 在 “ 作 崇 ”, 又 
是 谁 可 以 支撑 Docker 的 运行 并 提供 丰富 的 特性 ? 答案 很 简单 ， 那 就 


Linux 内 核 。 


那 我 们 就 从 Linux 内 核 的 角度 来 看 看 Docker 到 底 为 何 物 ， 先 从 
Docker 容 器 入 手 。 对 于 Docker 容 器 ， 体验 过 的 开发 者 都 有 两 点 非常 


重要 的 感受 : 内 部 可 以 跑 应 用 ( 进程 ) ， 以 及 提供 隔离 的 环境 。 当 
然 ， 后 者 肯定 也 是 工业 界 称 之 为 “容器 "的 原因 之 一 。 


首先 ，, 我们 先 来 看 Docker 容 颖 与 进程 的 关系 ， 或 者 容 莫 与 进程 的 
关系 。 为 了 理 清 这 两 者 之 间 的 关系 ， 我 不 妨 提出 这 样 一 个 问题 “ 容 莫 是 
否 可 以 脱离 进程 而 存在 ”"。 换 旬 话 说 就 是 ,能 否 创 建 一 个 容 右 ,而 这 个 
容 莫 内 部 没有 任何 进程 。 答 案 是 否定 的 。 既 然 答案 是 否定 的 ,说明 不 
可 能 先 有 容器 ， 然 后 再 有 进程 ， 那 么 问题 又 来 了 ,，“ 容 缆 和 进程 是 一 起 
诞生 的 ， 还 是 先 有 进程 再 有 容器 呢 ? “可 以 说 答案 是 后 者 。 以 下 将 慢 慢 
阐述 其 中 的 原因 。 


阐述 问题 “容器 是 否 可 以 脱离 进程 而 存在 "的 原因 前 ， 相 信 大 家 对 
于 下 面 这 段 话 不 会 有 异议 : 通过 Docker 创 建 出 的 一 个 Docker 
Container 是 一 个 容 需 ， 而 这 个 容 怖 提供 了 进程 组 隔离 的 运行 环境 。 
那么 问题 在 于 ， 容 欠 到 底 是 通过 什么 途径 来 实现 进程 组 运行 环境 的 “ 陋 
离 " 呢 ? 此 时 ， 就 轮 到 Linux 内 核 隆 重 登场 了 。 


说 到 运行 环境 的 “隔离 ”, 相信 大 家 肯定 对 Linux 内 核 中 的 
namespaces 和 cgroups 略 有 耳闻 ,namespaces 主 要 负责 命名 空 
间 的 隔离 ，cgroups 主 要 负责 资源 使 用 的 限制 。 其 实 ， 正 是 这 两 个 神 
奇 的 内 核 特 性 联合 使 用 ， 才 保证 了 Docker 容 肴 之 间 的 “隔离 "。 那 
么 , namespaces 和 cgroups 又 和 进程 有 什么 关系 呢 ? 问题 的 答案 可 
以 用 以 下 的 次 序 来 表示 : 


1) 父 进程 通过 fork 创 建 子 进程 时 ， 使 用 namespaces 技 术 , 实 
现 子 进程 与 父 进程 以 及 其 他 进程 之 间 命 名 空间 的 隔离 。 


2) 子 进 程 创建 完毕 之 后 ,使 用 cgroups 技 术 来 处 理 进程 ， 实 现 
进程 的 资源 限制 。 


3) namespaces 和 cgroups 这 两 种 技术 都 用 上 之 后 ， 进 程 所 处 
的 “隔离 "环境 才 真 正 建立 ， 此 时 “容器 "真正 诞生 |! 


从 Linux 内 核 的 角度 分 析 容 器 的 诞生 ， 精 简 的 流程 即 如 上 三 步 ， 
而 这 三 个 步骤 也 恰好 巧妙 地 阑 述 了 namespaces 和 cgroups 这 两 种 技 
术 和 进程 的 关系 ， 以 及 进程 与 容器 的 关系 。 进 程 与 容 蓝 的 关系 ， 自 然 
是 : 容器 不 能 脱离 进程 而 存在 ， 先 有 进程 ,后 有 容 右 。 然 而 ， 大 家 往 
往 会 说 到 “使 用 Docker 创 建 Docker 容 器 ， 然 后 在 容器 内 部 运行 进 
程 ”。 对 此 ， 从 通俗 易 懂 的 角度 来 讲 ， 这 完全 可 以 理解 ， 因 为 "“ 容 
絮 " 一 词 的 存在 , 本身 就 较为 抽象 。 如 果 需 要 更 为 准确 ， 可 以 表述 
为 “使 用 Docker 创 建 一 个 进程 ， 为 这 个 进程 创建 隔离 的 环境 ， 这 样 的 
环境 可 以 称 为 Docker 容 器 ， 然 后 再 在 容器 内 部 运行 用 户 应 用 进 
程 。” 在 这 里 ， 笔 者 的 本 意 不 是 希望 纠正 外 界 对 于 Docker 容 器 的 认 
识 ， 而 是 希望 能 和 读者 一 起 来 看 看 Docker 容 器 技术 实现 的 原理 到 底 几 
何 。 


更 清楚 地 认识 Docker 容 器 之 后 ， 很 快 大 家 的 眼球 肯定 会 定位 到 
namespaces 和 cgroups 这 两 种 技术 上 。Linux 内 核 的 这 两 种 技术 ， 
竟然 起 到 如 此 重大 的 作用 。 那 么 下 面 我 们 就 从 Docker 容 毁 实 现 流程 的 
角度 简要 介绍 这 两 者 。 


首先 讲述 一 人 namespace 在 容器 创建 时 的 用 法 。 用 户 局 动容 
硕 ，Docker Daemon 会 fork 出 容 疹 中 的 第 一 个 进程 A( 暂且 称 为 进 
程 A， 也 就 是 Docker Daemon 的 子 进 程 ) ， 执 行 fork 时 通过 5 个 参数 
标志 CLONE_ NEWNS、CLONE_NEWUTS、CLONE_NEWIPC、 
CLONE_PID 和 CLONE_NEWNET( Docker 1.2.0 还 没有 完全 支持 
user namespace) 。Clone 系 统 调 用 一 旦 传 入 了 这 些 参 数 标 志 ， 子 
进程 将 不 再 与 父 进程 共享 相同 的 命名 空间 ( namespaces) ， 而 是 由 
Linux 为 子 进程 创建 新 的 命名 空间 ( namespaces) ， 从 而 保证 子 进 
程 与 父 进程 使 用 隔离 的 环境 。 另 外 ， 如 果子 进程 A 再 次 fork 出 子 进程 
B , 而 fork 时 没有 传 入 相应 的 Namespaces 参 数 标志 时 ， 子 进程 B 将 
会 与 A 共享 相同 的 命名 空间 ( namespaces) 。 如 果 Docker 
Daemon 再 次 创建 一 个 Docker 容 器 ， 内 部 进程 有 DD、E 和 F， 那么 这 
三 个 进程 也 会 处 于 另外 全 新 的 namespaces 中 。 两 个 容 怖 的 
namespaces 均 与 Docker Daemon 上 所 在 的 namespaces 不 同 。 


Docker 中 Docker Daemon 与 Docker 容 肴 之 间 的 namespaces 关 
系 ， 如 图 7-1 所 示 。 


namespace 


fork with fork with 
clone flags clone flags 





图 7-1 Docker 的 namespaces 关 系 图 


再 说 起 cgroups， 大 家 都 知道 可 以 使 用 cgroups 为 进程 组 做 资源 
的 限制 。 与 namespaces 不 同 的 是 ， ee 
妖 内 进程 时 完成 ， 而 是 在 创建 容器 内 进程 之 后 完成 ， 最 终 使 得 容器 
程 处 于 资源 控制 的 状态 。 换 言 之 ,cgroups 的 运用 必须 要 等 到 容器 内 
第 一 个 进程 被 真正 创建 出 来 之 后 才能 实现 。 当 容器 内 进程 创建 完毕 ， 
Docker Daemon 可 以 获知 容器 内 主 进程 的 PID 信 息 ， 随 后 将 该 PID 放 
置 在 cgroups 文 件 系统 的 指定 位 置 ， 做 相应 的 资源 限制 。 如 此 一 来 ， 
当 容 器 主 进程 再 fork 新 的 子 进程 时 ， 新 的 子 进程 同样 受到 与 主 进程 相 
同 的 资源 限制 ， 效果 就 是 整个 进程 组 受到 资源 限制 。 


可 以 说 Linux 内 核 的 namespaces 和 cgroups 技 术 , 实现 了 资源 
的 隔离 与 限制 。 那 么 对 于 资源 的 隔离 ， 是 人 否 还 需要 为 容 左 准备 必需 的 


资源 ， 比 如 说 容 怖 需要 使 用 的 网 络 资源 ， 容 需 需 要 使 用 的 文件 系统 挂 
载 点 等 。 这 回答 案 是 肯定 的 。 网 络 资源 就 是 一 个 很 好 的 例子 。 当 
Docker Daemon 为 进程 创建 完 隔离 的 运行 环境 之 后 ， 我 们 可 以 发 现 
进程 并 没有 独立 的 网 络 栈 可 以 使 用 ， 如 独立 的 网 络 接口 等 。 此 时 ， 
Docker Daemon 会 将 Docker 容 器 内 部 所 需要 的 资源 一 一 配备 齐 

全 。 网 络 方面 ， 即 为 Docker 容 器 通过 用 户 指定 的 网 络 模式 ， 配 置 相应 
的 网 络 资源 。 


本 章 从 源码 的 角度 ， 分 析 Docker 容 器 从 无 到 有 的 过 程 中 ， 
Docker 容 器 网 络 创建 的 来 龙 去 脉 。 简 化 而 言 ，Docker 容 莫 网 络 的 创 
建 流程 如 图 7-2 所 示 。 





图 7-2 ”Docker 容 器 网 络 创建 流程 图 
本 章 分 析 的 主要 内 容 有 以 下 5 部 分 : 
:Docker 容 问 的 网 络 模式 
:Docker Client 配 置 容 器 网 络 
:Docker Daemon 创 建 容器 网 络 流程 
'execdriver 网 络 执 行 流程 
:jibcontainer 实 现 内 核 态 网 络 配置 


在 Docker 容 器 的 网 络 创建 过 程 中 ,networkdriver 模 块 使 用 并 非 
是 重点 ， 故 分 析 内 容 中 不 涉及 networkdriver。 不 少 读者 肯定 会 有 一 
些 疑 惑 ， 为 什么 Docker 容 怖 的 网 络 创建 很 少 用 到 networkdriver。 这 
里 强调 一 下 networkdriver 在 Docker 中 的 作用 : 第 一 ,为 Docker 
Daemon 创 建 网 络 环境 的 时 候 ， 初 始 化 Docker Daemon 的 网 络 环境 
( 详 见 第 6 章 ) ， 比 如 创建 docker0 网 桥 等 ; 第 二 ，, 为 Docker 容 器 分 
配 IP 地 址 ， 为 Docker 容 硕 做 端口 映射 等 。 而 与 Docker 容 闫 网 络 创建 
有 关 的 内 容 并 不 多 ， 如 只 在 桥接 模式 下 ， 为 Docker 容 硕 的 网 络 接口 设 


备 分 配 一 个 IP 地 址 。 


7.2 Docker 容 器 网 络 模式 


如 前 所 述 ， Dockero 以 为 容 怖 创建 隔离 的 网 络 环境 ， 在 隅 离 的 网 
络 环境 下 ，Docker 容 兹 使 用 独立 的 网 络 栈 。 看 到 这 ,很 多 读者 也 许 会 
非常 赞成 以 上 的 言论 。 然 而 ，Docker 容 凑 网 络 的 高 级 特性 又 会 让 爱好 
者 们 感受 到 其 中 暗藏 的 更 多 玄机 。 


奔 主题 ， 其 实 Docker 除 可 以 为 Docker 容 器 创建 隔离 的 网 络 环 
境 之 外 ,同样 有 能 力 为 Docker 容 怖 创建 共享 的 网 络 环境 。 换 言 之 , 当 
开发 者 需要 Docker 容 闸 与 得 主机 或 者 其 他 容 闫 网 络 隔离 ，Docker 可 
以 满足 这 样 的 需求 ; 当 开 发 者 需要 Docker 容 器 的 网 络 处 于 共享 的 网 络 
环境 时 ，Docker 同 样 可 以 满足 这 样 的 需求 ， 并 且 网 络 共享 ， 可 以 是 
Docker 容 希 与 簿 主 机 之 间 网 络 共 享 ， 也 可 以 是 Docker 容 怖 与 其 他 容 
器 之 间 网 络 共享 。 神 奇 的 是 ，Docker 还 可 以 实现 不 为 Docker 容 器 创 
建 网 络 环境 。 


通过 以 上 描述 ， 可 以 总 结 出 Docker 容 器 共有 以 下 4 种 网 络 模式 : 
bridge 桥 接 模 式 、host 模 式 、other container 模 式 和 none 模 式 。 
下 面 分 别 介 绍 Docker 的 4 种 网 络 模 式 。 


7.2.1 bridge 桥接 模式 


Docker 容 硕 的 bridge 桥 接 模式 是 目前 Docker 开 发 者 中 使 用 最 为 
广泛 的 网 络 模式 。bridge 桥 接 模式 可 以 使 Docker 容 希 独 立 使 用 网 络 
栈 ， 或 者 说 只 有 在 容 需 内 部 的 进程 ， 才 能 使 用 该 网 络 栈 。bridge 桥 接 
模式 的 实现 步骤 如 下 。 


1) 利用 veth pair 技 术 ,在 宿主 机 上 创建 两 个 虚拟 网 络 接口 ， 仿 
设 为 veth0 和 veth1。 而 veth ee 
veth 接 收 到 网 络 报 文 ， 都 会 将 报 文 传输 给 另 


2) Docker Daemon 将 veth0 附 加 到 Docker Daemon 创建 的 
docker0 网 桥 上 。 保 证 入 主机 的 网 络 报 文 有 能 力 发 往 veth0。 


3) Docker Daemon 将 veth1 添 加 到 Docker 容 器 所 属 的 网 络 命 
名 空间 ( namespaces) 下 ，veth1l1 在 Docker 容 器 看 来 就 是 eth0。 
一 方面 ， 保 证 箱 主 机 的 网 络 报 文 若 发 往 veth0， 可 以 立即 被 veth] 收 
到 ,实现 簿 主机 到 Docker 容 希 之 间 网 络 的 联通 性 ; 另 一 方面 ， 保 证 
Docker 容 希 单 独 使 用 veth1， 实现 容 希 之 间 以 及 容 希 与 稍 主 机 之 间 网 
络 环境 的 隔离 性 。 


Docker 容 器 的 bridge 桥 接 模式 如 图 7-3 所 示 。 





docker0(bridge) 








图 7-3 ”Docker 容 器 bridge 桥 接 模式 示意 图 


bridge 桥 接 模式 ， 从 原理 上 实现 了 Docker 容 钴 到 箱 主 机 乃至 其 他 
机 兹 的 网 络 联通 性 。 然 而 ， 由 于 答 主 机 的 IP 地 址 与 veth pair 的 IP 地 址 
不 属于 同一 个 网 段 ， 故 仅仅 依靠 veth pair 和 网 络 命 名 空间 的 技术 ,还 
不 足以 使 稍 主 机 以 外 的 网 络 主动 发 现 Docker 容 需 的 存在 。 为 使 
Docker 容 右 有 能 力 让 宿主 机 以 外 的 世界 感受 到 容 妖 内 部 暴露 的 服务 ， 
Docker 采 用 NAT( Network Address Translation ， 网络 地 址 转换 ) 
的 方式 让 得 主机 以 外 的 世界 可 以 将 网 络 报 文 发 送 至 容 郑 内 部 。 简 要 来 
讲 ， 当 Docker 容 希 需 要 暴露 服务 时 ， 内 部 服务 必须 监听 容 郑 IP 和 容 尼 
内 部 端口 号 port_0， 以 便 外 界 主动 发 起 访问 请 求 。 由 于 答 主 机 以 外 的 
世界 ， 只 知道 宿主 机 eth0 的 网 络 地址 ,并 不 知道 Docker 容 间 的 IP 地 
址 ,哪怕 就 算 知 道 Docker 容 器 的 IP 地 址 ,从 二 层 网 络 的 角度 来 讲 ,外 
界 也 无 法 直接 通过 Docker 容 器 的 IP 地 址 访问 容器 内 部 的 服务 。 因 此 ， 


Docker 使 用 NAT 方 法 ,将 容 问 内 部 的 服务 与 宿主 机 的 某 一 个 端口 


port_1 进 行 “ 绑 定 "。 
如 此 一 来 ， 外 界 访问 Docker 容 痪 内 部 服务 的 流程 为 : 
1) 外 界 访问 牡 主机 的 IP 以 及 香 主 机 的 端口 port_1。 


2) 当 往 主机 接收 到 这 类 请 求 之 后 ， 由 于 存在 DNAT 规 则 ， 会 将 该 
请 求 的 目 的 IP( 衍 主机 eth0 的 IP) 和 目 的 端口 port_1 进 行 符 换 ,替换 


as OO Da OO 


为 容器 IP 和 容器 端口 port_0。 


3) 由 于 能 够 识别 容 怖 |IP， 故 箱 主 机 可 以 将 请 求 发 送 给 veth 


pair, 
4) veth pair 将 请 求 发 送 至 容 右 ， 容 姨 交 于 内 部 服务 进行 处 理 。 


使 用 DNAT 方 法 ， 可 以 使 Docker 宿 主机 以 外 的 世界 主动 访问 
Docker 容 姻 。 那 么 Docker 容 器 如 何 访问 往 主 机 以 外 的 世界 呢 ? 以 下 
简要 分 析 Docker 容 怖 内 部 访问 利 主 机 以 外 世界 的 流程 : 


1) Docker 容 硕 内 部 进程 获 荡 稍 主 机 外 部 服务 的 IP 地 址 和 癌 
port_2 ,于 是 Docker 容 需 发 起 请 求 。 容 硕 独 立 的 网 络 环境 保证 了 请 求 
中 报 文 的 源 IP 地 址 为 容 希 IP( 即 容 需 内 部 eth0 ,veth pair 一 方 的 IP 地 
址 ) ， 男 外 Linux 内 核 会 自动 为 进程 分 配 一 个 可 用 端口 ( 假设 为 
port 3) 。 


2) 请 求 通 过 容器 内 部 eth0 发 送 至 veth pair 的 另 一 端 ， 也 就 是 到 
达 网 桥 docker0 处 。 


3) docker0 网 桥 开 局 了 数据 报 转 发 功能 
( /proc/sys/netipv4/ip_ forward) ， 故 docker0 将 请 求 发 送 至 簿 主 
机 的 eth0 处 。 


4) 答 主 机 处 理 请 求 时 ， 使 用 SNAT 对 请 求 进行 源 地 址 IP 蔡 换 ， 即 
将 请 求 中 源 地 址 IP( 容器 eth0 的 IP 地 址 ) 车 换 为 宿主 机 eth0 的 IP 地 
址 。 


5) 条 主机 将 经 过 SNAT 处 理 后 的 报 文 通过 请 求 的 目 的 IP 地 址 ( 窜 
主机 以 外 世界 的 IP 地 址 ) 发 送 至 外 界 。 


在 这 里 ， 很 多 人 肯定 要 问 : 对 于 Docker 容 器 内 部 主动 发 起 对 外 的 
网 络 请 求 ， 请 求 到 达 宿 主机 进行 SNAT 处 理发 给 外 界 之 后 ， 当 外 界 响应 
请 求 时 ， 响 应 报 文中 的 目 的 IP 地 址 肯定 是 Docker Daemon 所 在 宿主 
机 的 IP 地 址 ， 那 响应 报 文 回 到 宿主 机 的 时 候 ， 宿 主机 又 是 如 何 转 给 
Docker 容 器 的 呢 ? 关于 这 样 的 响应 ， 由 于 没有 做 相应 的 DNAT 转 换 ， 
原则 上 不 会 被 发 送 至 容器 内 部 。 为 什么 说 对 于 这 样 的 响应 ,不 会 做 
DNAT 转 换 呢 。 原 因 很 简单 ，DNAIT 转 换 是 针对 特定 容 次 内 部 服务 监听 
的 特定 端口 做 的 ， 该 端口 是 供 服务 监听 使 用 ,而 容 蓝 内 部 发 起 的 请 求 


报 文 中 ， 源 剖 口 号 肯定 不 会 占用 服务 监听 的 痛 口 ， 故 容 闫 内 部 发 起 请 
求 的 响应 不 会 在 和 从 主机 上 经 过 DNAT 处 理 。 


其 实 ， 这 一 环节 的 关键 在 于 iptables , 具体 的 iptables 规 则 如 
下 : 


iptables -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j 
ACCEPT 


此 iptables 规 则 的 意思 是 : 在 入 主机 上 发 往 docker0 网 桥 的 网 络 
数据 报 文 ， 如 果 该 数据 报 文 所 处 的 连接 已 经 建立 ， 则 无 条 件 接受 ， 并 
由 Linux 内 核 将 其 转 人 至 原来 的 连接 上 ， 即 回 到 Docker 容 器 内 部 。 


以 上 便 是 Docker 容 颖 中 bridge 桥 接 模式 的 简要 介绍 。 可 以 说 ， 
bridger 桥 接 模式 实现 了 两 个 方面 : 第 一 ， 让 容器 内 部 使 用 独立 的 网 络 
栈 ; 第 二 ， 让 容 费 和 宿主 机 以 外 的 世界 通过 NAT 建 立 通 信 。 从 功能 
角度 来 讲 ， 恰 似 具 备 了 传统 情况 下 隔离 环境 中 网 络 的 功能 。 然 而 ， 从 
使 用 的 角度 来 讲 ， 这 种 方式 还 没有 弥合 传统 网 络 环 境 与 容器 网 络 环境 
的 缝隙 ， 换 言 之，NAT 方 式 必 须 使 得 容 颖 服务 在 宿主 机 上 有 一 层 抽 
象 ， 这 层 抽象 需要 Docker 使 用 者 人 为 的 干涉 ， 另 外 使 用 NAT 方 式 ， 仪 
仅 是 三 层 网 络 上 的 实现 手段 ， 影 响 网 络 传输 效率 的 同时 ， 也 会 为 网 络 
的 隔离 带 来 不 便 。 


7.2.2 ”host 模式 


Docker 容 器 中 的 host 模 式 与 bridge 桥 接 模式 是 完全 不 同 的 模式 。 
最 大 的 区 别 是 : host 模 式 并 没有 为 容 闫 创建 一 个 隔离 的 网 络 环境 。 之 
所 以 称 之 为 host 模 式 ， 是 因为 该 模式 下 的 Docker 容 希 会 和 host 簿 主机 
使 用 同一 个 网 络 命名 空间 , 故 Docker 容 器 可 以 和 宿主 机 一 样 ， 使 用 宿 
主机 的 eth0 和 外 界 进行 通信 。 如 此 一 来 ，Docker 容 闫 的 IP 地 址 自然 也 
是 宿主 机 eth0 的 IP 地 址 。 


Docker 容 怖 的 host 网 络 模式 如 图 7-4 所 示 。 


图 7 -4 中 最 左 侧 的 Docker 容 器 ， 即 采用 了 host 网 络 模式 ， 而 其 他 
两 个 Docker 容 莫 依 然 沿用 brdige 桥 接 模 式 ， 两 种 模式 存在 于 同一 个 入 
主机 上 并 不 矛盾 。 
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图 7-4 Docker 容 器 host 网 络 模式 示意 多 


Docker 容 希 的 host 网 络 模式 在 实现 过 程 中 ， 由 于 不 需要 额外 的 网 
桥 以 及 虚拟 网 卡 ， 故 不 会 涉及 docker0 以 及 veth pair。 上 文 
namespace 的 介绍 中 曾经 提 到 : 父 进程 在 创建 子 进 程 的 时 候 ， 如 有 果 不 
使 用 CLONE_NEWNET 这 个 参数 标志 ， 那么 创建 出 的 子 进程 会 与 其 父 

程 共享 同一 个 网 络 命名 空间 。Docker 就 是 采用 了 这 个 简单 的 原理 ， 
在 创建 进程 后 动容 硕 的 过 程 中 ,没有 传 入 CLONE_NEWNET 参 数 标 
志 ， 实 现 Docker 容 希 与 福 主 机 共享 同一 个 网 络 环境 ， 网 络 模式 即 为 
host 网 络 模式 。 


Docker 容 器 的 网 络 模式 中 ，host 模 式 是 bridge 桥 接 模式 很 好 的 补 
充 。 膝 用 host 模 式 的 Docker 容 器 ， 可 以 直接 使 用 宿主 机 的 IP 地 址 与 外 
界 进行 通信 , 若 宿 主机 的 eth0 是 一 个 公有 IP， 那么 容器 的 IP 也 拥有 这 


个 公有 IP。 同 时 容 莫 内 服务 的 端口 也 可 以 使 用 答 主 机 的 妆 口 ， 无 需 额 
外 进行 NAT 转 换 。 有 这 样 的 方便 ， 自 然 会 折 损 部 分 其 他 的 特性 ， 最 明 
显 的 即 是 Docker 容 壤 网 络 环境 的 隔离 性 。 另 外 ， 使 用 host 模 式 的 
Docker 容 希 虽 然 可 以 让 容 闫 内 部 的 服务 无 差别 、 无 改造 的 使 用 ,但 是 
由 于 网 络 的 非 隔离 性 ,一旦 答 主 机 上 多 个 Docker 容 右 都 六 用 了 host 模 
式 ， 并 且 内 部 的 服务 都 需要 占用 相同 的 答 主 机 端口 资源 ， 此 时 会 造成 
答 主 机 上 端口 资源 的 竞争 ， 势 必 影 响 容 颖 的 服务 质量 。 


7.2.3 other container 模 式 


Docker 容 器 的 other container 网 络 模 式 是 Docker 中 一 种 较为 
特别 的 网 络 模 式 。 之 所 以 称 为 “other container 模 式 ”, 是 因为 这 个 
模式 下 的 Docker 容 硕 ， 会 使 用 其 他 容 怖 的 网 络 环境 。 之 所 以 称 为 “ 特 
别 ”, 是 因为 这 个 模式 下 容 旨 的 网 络 隔离 性 会 处 于 bridge 桥 接 模 式 与 
host 模 式 之 间 。Docker 容 怖 共享 其 他 容 毁 的 网 络 环境 ， 则 至 少 这 两 
个 容 背 之 间 不 存在 网 络 隔离 ， 而 这 两 个 容 闫 又 与 宿主 机 以 及 除 此 之 外 
其 他 的 容器 存在 网 络 隔离 。 


Docker 容 器 的 other container 网 络 模 式 如 图 7-5 所 示 。 


图 7-5 中 和 右 侧 的 Docker 容 器 即 采 用 了 other container 网 络 模 
式 ， 它 具体 能 感受 到 网 络 环 境 即 为 左 侧 Docker 容 器 的 bridge 桥 接 模 


在 Docker 容 器 的 other container 网 络 模 式 实现 过 程 中 ， 不 涉及 
网 桥 ， 同 样 也 不 需要 创建 虚拟 网 卡 veth pair。 完 成 other container 
网 络 的 创建 只 需要 两 个 步 又 : 


1) 查找 other container( 即 需要 被 共享 网 络 环 境 的 容器 ) 的 网 
络 命名 空间 。 


2) 新 创建 的 Docker 容 器 的 网 络 命 名 空间 使 用 其 他 容器 的 网 络 命 


名 空间 。 
Docker Container 
ET 
docker0 (bridge) 


ipv4 ip forward 
















Host 








图 7-5 ”Docker 容 器 other container 网 络 模 式 示 意图 


Docker 容 器 的 other container 网 络 模式 ， 可 以 用 来 更 好 地 服务 
于 容器 间 的 通信 。 需 要 互相 通信 和 的 Docker 容 器 在 这 种 模式 下 ,虽然 网 
络 隔离 性 没有 bridge 桥 接 模式 优秀 ， 但 是 相 比 host 模 式 自然 要 好 不 
少 ， 同 时 网 络 隔离 性 稍 有 弱化 的 背后 ， 理 来 的 却 是 容 问 间 高 效 的 传输 
效率 ， 以 及 容 闫 间 互 访 时 简约 的 网 络 配置 ， 即 只 需要 使 用 localhost 来 
访问 其 他 容 句 。 同 时 ， 多 个 容 闫 共享 同一 个 网 络 命令 空间 的 形式 ， 使 
得 这 部 分 容 冀 的 粘性 大 大 提高 。 在 容 闫 的 大 规模 调度 与 管理 中 ， 容 需 
组 必然 会 是 一 个 需要 攻克 的 技术 点 ， 而 other container 网 络 模式 似 
乎 为 容器 组 的 实现 提供 了 方向 。 值 得 思考 的 是 ，Google 推 出 的 


Kubernetes 平 台中 的 Pod 的 原理 ,即使 用 了 容器 间 共 享 网 络 命名 空间 
的 思路 ， 实 现 了 组 的 概念 。 


7.2.4 none 模 式 


Docker 容 器 的 第 4 种 网 络 模 式 是 none 模 式 。 顾 名 思 义 ， 网 络 环 
境 为 none ，, 即 不 为 Docker 容 器 创建 任何 的 网 络 环境 。 一 旦 Docker 容 
帮 采 用 了 none 网 络 模式 ， 那么 容器 内 部 就 只 能 使 用 loopback 网 络 接 
口 ， 不 会 再 有 其 他 的 网 络 资源 。 


可 以 说 none 模 式 为 Docker 容 痪 做 了 极 少 的 网 络 设 定 ， 但 是 俗话 
说 得 好 “ 少 即 是 多 ”, 在 没有 网 络 配置 的 情况 下 ， 作 为 Docker 开 发 
者 ， 才 能 在 这 种 模式 下 做 无 限 多 可 能 的 网 络 定制 开发 。 这 也 恰恰 体现 
了 Docker 开 放 的 设计 理念 。 


至 此 ,Docker 的 4 种 网 络 模式 的 介绍 就 告 一 段落 ,下文 带 来 
Docker 网 络 模式 的 创建 流程 分 析 。 


7.3 Docker Client 配 置 容 绒 网 络 模式 


Docker 容 盔 网 络 模式 的 多 样 性 ， 极 大 地 满足 了 Docker 用 户 部 署 
应 用 的 网 络 需求 。Docker 有 用户， 或 者 基于 Docker 的 二 次 开发 者 , 均 
可 以 在 这 基础 上 ,选择 使 用 与 自身 应 用 最 为 贴切 的 网 络 模式 。 


从 图 7-2 中 可 以 看 到 ，Docker 容 郑 网 络 创建 流程 中 第 一 个 涉及 的 
Docker 模 块 就 是 Docker Client。 当 然 ， 这 也 容易 理解 ， 毕 竟 
Docker 容 希 网 络 环境 的 创建 需要 由 用 户 发 起 。 用 户 根据 自身 对 容 需 的 
需求 ， 选 择 网 络 模式 ， 并 将 其 通过 Docker Client 传 递 给 Docker 
Daemon。 本 小 节 将 从 Docker Client 源 码 的 角度 出 发 ， 分 析 如 何 通 
过 参数 的 形式 配置 Docker 容 希 的 网 络 模式 ， 以 及 Docker Client 内 部 
如 何 处 理 这 些 网 络 模式 参数 。 


7.3.1 使 用 Docker Client 


Docker 架 构 中 ， 用 户 完全 可 以 使 用 Docker Client 来 配置 
Docker Container 的 网 络 模式 。 实 际 情况 下 ， 局 动 一 个 容 怖 ， 
Docker 才 会 为 Docker 容 硕 创 建 网 络 环境 ， 故 配置 网 络 模式 在 用 户 执 
行 “ 启 动容 妖 " 命 令 之 后 完成 。 启 动容 匡 命 令 为 docker run， 通 过 
Docker Client 发 起 ， 使 用 方式 如 下 所 示 ( 其 中 NETWORKMODE 为 
四 种 网 络 模 式 之 一 ，IMAGE_NAME 为 镜像 名 称 ) 


docker run -it--net NETWORKMODE IMAGE NAME /bin/bash 


执行 以 上 命令 时 ，Docker 首 先 创 建 一 个 Docker Client , 再 由 
Docker Client 解 析 整 条 命令 的 请 求 内 容 ， 最 终 解析 为 run 命 令 ， 并 发 


送 至 Docker Daemon。Docker Client 的 相关 实现 详 见 本 书 第 2 章 。 


7.3.2 runconfig 包 解析 


解析 出 run 命 令 之 后 ,Docker Clienti 调 用 相应 的 处 理 明 数 
cmdRun 处 理 关 于 run 请 求 的 具体 内 容 。CmdRun 蝎 数 的 实现 位 
于 ./docker/docker/api/client/commands.go#L1990, CmdRun 
执行 的 第 一 步 就 是 : 通过 runconfig 包 中 的 ParseSubcommand 纹 数 
执行 解析 出 相应 的 config、hostConfig， 以 及 cmd 对 象 ， 源 码 实现 如 
下 : 


TORTISNS] TAGE Te Re 
其 中 ,config 的 类 型 为 Config 结 构 体 ，hostConfig 的 类 型 为 
HostConfig 结 构 体 ， 两 种 类 型 的 定义 均 位 于 runconfig 包 。Config 与 
HostConfig 类 型 同 用 以 描述 Docker 容 器 的 配置 信息 ， 然 而 两 者 之 间 

又 有 着 本 质 的 区 别 ， 它们 各 自 的 描述 如 下 : 


:Config 结 构 体 : 描述 Docker 容 器 独立 的 配置 信息 。 独 立 的 含义 
是 : Config 这 部 分 信息 描述 的 是 容器 本 身 ， 而 不 会 与 容器 所 在 宿主 机 
相关 。 

:HostConfig 结 构 体 : 描述 Docker 容 器 与 宿主 机 相关 的 配置 信 


自 
/No 


ea ， 
有 属性 正 是 说 明了 这 一 


1.Config 结 构 体 


而 结构 体内 的 所 
点 ， 结 构 体 的 定义 如 下 : 


type Config struct { 


Hostname 
Domainname 
User 
Memory 
MemorySwap 


disable 


if 


CpuShares 
Cpuset 
AttachStdin 
AttachStdout 
AttachStderr 
PortSpecs 
ExposedPorts 
Tty 


OpenStdin 
StdinOnce 


Env 
Cmd 
Image 


Volumes 
WorkingDir 
Entrypoint 


string 

string 

string 

int64 // Memory Limit (in bytes) 

int64 // Total memory usage (memory + Swap); set '-1' to 


//swap 

int64 // CPU shares (relative weight vs. 
string // Cpuset 0-2, 0,1 

bool 

bool 

bool 

[]string // Deprecated - Can be in the format of 8080/tcp 
map[nat.Port]struct{} 

bool  // Attach standard streams to a tty, including stdin 


other containers) 


// it is not closed. 

// Open stdin 

// If true, close stdin after the 1 attached client 

// disconnects. 

[]string 

[]string 

string // Name of the image as it was passed by the 
// operator (eg. could be symbolic) 

map[lstring]struct{} 

string 

[]string 


bool 
bool 


NetworkDisabled bool 


OnBuild 


[]string 


Config 结 构 体 中 各 属性 的 详细 说 明 如 表 7 -1 所 示 。 


表 7-1 Config 结 构 体 属性 介绍 表 


Config 结构 体 属性 名 


类 型 代表 含义 
























































Hostname string 容器 主机 名 

Domainname string 域名 服务 器 名 称 

User string 容器 内 用 户 名 

Memory int64 容器 的 内 存 使 用 上 限 (单位 : 字 节 ) 

MemorySwap int64 容器 所 有 的 内 存 使 用 上 限 (物理 内 存 + 交 互 区 )， 关 闭 交 互 

区 支持 置 为 -1 

CpuShares int64 容器 CPU 使 用 share 值 ， 其 他 容器 的 相对 值 

Cpuset string CPU 核 的 使 用 集合 

AttachStdin bool 是 否 附加 标准 输入 

AttachStdout bool 是 否 附 加 标准 输出 

AttachStderr | bool | 是 否 附 加 标准 出 错 

( 续 ) 

Config 结构 体 属性 名 代表 含义 

PortsSpecs 已 弃 用 

ExposedPorts 容器 内 部 暴露 的 端口 号 

Tty 是 否 分 配 一 个 伪 终 端 tty 

OpenStdin bool 在 没有 附加 标准 输入 时 ， 是 否 依然 打开 标准 输入 

StdinOnce bool 若 为 真 ， 表 示 当 一 个 客户 关闭 标准 输入 后 关闭 容器 的 标准 输入 

Env [string 容器 的 环境 变量 ， 可 以 有 多 个 

Cmd [string 容器 内 运行 的 指令 (一 个 或 多 个 ) 

Image string 容器 rootfs 所 依赖 的 镜像 名 称 

Volumes mapl[string]struct{} 容器 从 宿主 机 上 挂 载 的 目录 

WorkingDir string 容器 内 部 进程 的 指定 工作 目录 

Entrypoint 覆盖 镜像 中 默认 的 ENTRYPOINT 

NetworkDisabled 是 否 关闭 容器 网 络 功能 

OnBnuild [string 指定 的 命令 在 构建 镜像 时 不 执行 ， 而 是 在 镜像 构建 完成 之 后 

wn 
2.HostConfig 结 构 体 


HostConfig 结 构 体 描述 Docker Container 与 宿主 机 相关 的 属性 
言 息 ， 结 构 体 的 定义 如 下 : 





type HostConfig struct { 


Binds []string 
ContainerIDFile string 

LxcConf [lJutils.KeyValuePair 
Privileged bool 


PortBindings nat.PortMap 


Links []string 
PubLishALLPorts bool 


Dns []string 
DnsSearch []string 
VoLumesFrom []string 
Devices []DeviceMapping 
NetworkMode NetworkMode 
CapAdd []string 
CapDrop []string 
RestartPolicy RestartPolicy 





Config 结 构 体 中 各 属性 的 详细 说 明 如 表 7 -2 所 示 。 


表 7-2 HostConfig 结 构 体 属性 介绍 表 














HostConfig 结构 体 属 性 名 类 型 代表 含义 
Binds []string 从 宿主 机 上 绑 定 到 容器 的 volumes 
ContainerIDFile string 文件 名 ,文件 用 以 写 人 容器 的 ID 
( 续 ) 
HostConfig 结构 体 属性 名 类 型 代表 含义 
LxcConf [lutils.KeyValuePair 添加 自 定义 的 xc 选项 键 值 对 
Privileged bool 是 否 将 容器 设置 为 特权 模式 
PortBindings nat.PortMap 容器 绑 定 到 宿主 机 的 端口 
Links [Jstring 与 其 他 容器 之 间 的 link 信息 
PublishAllPorts bool 是 否 在 宿主 机 上 映射 容器 所 有 的 端口 信息 
Dns []string 自 定 义 的 DNS 服务 器 地 址 
DnsSearch [lstring 自 定义 的 DNS 查找 服务 器 地 址 
VolumesFrom [lstring 将 自身 volumes 挂 载 到 此 容器 的 容器 
Devices [IDeviceMapping 为 容器 添加 一 个 或 多 个 宿主 机 设备 
NetworkMode NetworkMode 为 容器 设置 的 网 络 模 式 
CapAdd [Jstring 为 容器 用 户 添加 一 个 或 多 个 Linux Capabilities 
CapDrop [Jstring 为 容器 用 户 禁 用 一 个 或 多 个 Linux Capabilities 
RestartPolicy RestartPolicy 当 一 个 容 需 退出 时 采取 的 重启 策略 


3.runconfig 解 析 网 络 模式 


分 析 完 Config 与 HostConfig 结 构 体 之 后 ， 回 到 runconfig 包 中 分 
析 Docker Client 如 何 解析 与 Docker 容 背 网 络 模式 相关 的 配置 信息 ， 


并 将 这 部 分 信息 传递 给 config 实 例 与 hostConfig 实 例 。 


runconfig 包 中 的 ParseSubcommand 喘 数 调 用 parseRun 子 数 
完成 命令 请 求 的 分 析 ， 实现 代码 位 
于 ./dockerdockervrunconfig/parse.go##L37-L39 , 如 下 所 示 : 


func ParseSubcommand (cmd *flag.FlagSet, args []string，SsysInfo *sysinfo.SysInfo) 
(*Config, *HostConfig, *flag.FlagSet, error) { 

return parseRun(cmd, args, sysinfo) 
} 


进入 parseRun 销 数 即 可 发 现 ， 该 肖 数 完成 了 四 方面 的 工作 : 
:定义 与 容 右 配置 信息 相关 的 flag 参 数 。 


:解析 docker run 命 令 后 紧 跟 的 请 求 内 容 ， 将 请 求 内 容 全 部 保存 至 
flag 参 数 中 。 


:通过 flag 参 数 验证 参数 的 有 效 性 ， 并 处 理 得 到 Config 结 构 体 与 
HostConfig 结 构 体 需要 的 属性 值 。 


创建 并 初始 化 Config 类 型 实例 config、HostConfig 类 型 实例 
hostConfig， 最 终 返 回 Conffig、hostConfig 与 cmd。 


本 章 分 析 Docker 容 怖 的 网 络 模式 ， 而 parseRun 希 数 中 有 关 容 善 
网 络 模式 的 flag 参 数 有 flINetwork 与 NetMode , 两 者 的 定义 分 别 位 


于 ./docker/docker/runconfig/parse.go#L62 
与 ./docker/runconfig/parse.go#L75 , 如 下 所 示 : 


fLNetwork = cmd.Bool([]string{"#n", "#-networking"}, true, "Enable networking for 
this container") 

flNetMode = cmd.String([]string{"-net"}, "bridge", "Set the Network mode for the 
container\n'bridge': creates a new network stack for the container on the docker 
bridge\n'none': no networking for this container\n'container:<name| id>': reuses 
another container network stack\n'host': use the host network stack inside the 
container. Note: the host mode gives the container full access to local system 
services Such as D-bus and is therefore considered insecure.") 


可 见 flag 参 数 fNetwork 表 示 是 否 开局 容 怖 的 网 络 模式 ， 若 为 true 
则 开启 ， 说 明 需 要 给 容 旭 创建 网 络 环 境 ; 否则 不 开局， 说 明 不 给 容 需 
赋予 网 络 功能 。 此 flag 参 数 的 默认 值 为 true， 另 外 使 用 该 fag 的 方式 
为 : 在 docker run 之 后 设 定 --networking 或 者 -n， 由 于 fNetwork 的 
名 称 为 {##n"” ，"#-networking"} , 故 可 以 判定 此 flag 已 经 处 于 茎 用 


男 一 个 flag 参 数 INetMode 则 表示 用 户 为 容器 设 定 的 网 络 模式 ， 
共有 四 种 选项 分 别 是 : bridge、none、container : <namelid> 和 
host。 四 种 模式 的 作用 上 文 已 经 有 所 介绍 ， 此 处 不 再 殴 述 。 使 用 此 
flag 的 方式 为 : 在 docker run 之 后 设 定 --net , 如: 


docker run -it --net host IMAGE NAME /bin/bash 


用 户 使 用 docker run 启 动容 器 时 设 定 了 以 上 两 个 flag 参 数 ( 实际 
只 有 fNetMode 一 个 flag 参 数 ) ， 则 runconfig 包 会 解析 出 这 两 个 flag 


的 值 。 最 终 ， 通 过 flag 参 数 fINetwork ,得 到 Config 类 型 实例 Config 
的 属性 NetworkDisabled ; 通过 flag 参 数 flINetMode， 得 到 
HostConfig 类 型 实例 hostConfig 的 属性 NetworkMode。 


限 数 parseRun 返 回 config、hostConfig 与 cmd , 代表 着 
runconfig 包 解析 配置 参数 工作 的 完成 ， 下 一 节 将 回 到 CmdRun 的 运 


一 


休 。 


7.3.3 CmdRun 执 行 


在 runconfig 包 中 ，Docker Clien 纪 经 将 有 关 容 器 网 络 模 式 的 配 
置 置 于 config 对 象 与 hostConfig 对 象 ， 故 在 CmdRun 纹 数 的 执行 
中 ,更 多 的 是 基于 config 对 象 与 hostConfig 参 数 的 配置 信息 处 理 ， 而 
没有 其 他 的 容 问 网 络 处 理 部 分 。 


CmdRun 的 主要 工作 是 : 利用 Docker Daemon 暴 替 的 RESTful 
API 接 口 ， 将 docker run 的 请 求 发 送 至 Docker Daemon。CmdRun 
执行 过 程 中 Docker Client 与 Docker Daemon 的 简易 交互 如 图 7-6 所 


未 。 


从 CmdRun 的 执行 流程 中 ， 我们 可 以 发 现 : 在 解析 config、 
hostConfig 与 cmd 之 后 ，Docker Client 首 先 发 起 请 求 create 
container。 若 Docker Daemon 关 于 该 容器 的 镜像 存在 ， 则 立即 执 
行 create container 操 作 并 返回 请 求 响应 ; Docker Client 收 到 响应 
后 , 再 发 起 请 求 start container。 若 容器 镜像 还 不 存在 ，Docker 
Daemon 返 回 一 个 404 的 错误 ， 表 示 镜 像 不 存在 ; Docker Client 收 
到 错误 响应 之 后 ， 再 发 起 一 个 请 求 pull image , 使 Docker Daemon 
首先 下 载 镜像 ， 下载 完 之 后 Docker Client 再 次 发 起 请 求 create 


container , Docker Daemon 创建 完 之 后 , Docker Client 最 终 发 起 


请 求 start Container。 


Docker Client Docker Daemon 


YES 


iob, run () 
{create container) 






parse contig, 
hostConfig, cmd 


create container 
{with config) 


Ero 


AgCPS/ 
$s 


start container 


(with hostCofig) 





图 7-6 Docker Client 与 Docker Daemon 交 互 图 


其 中 关于 Docker 容 闫 网 络 模式 的 参数 配置 均 存 储 于 config 与 
hostConfig 对 象 之 中 ， 在 请 求 create container 和 start container 
发 起 后 ， 随 请 求 一 起 发 送 至 Docker Daemon。 


7.4 Docker Daemon 创 建 容 器 网 络 流程 


Docker Daemon 接 收 到 Docker Client 的 请 求 可 以 分 为 两 次 ， 
第 一 次 为 Create container ,第 二 次 为 start container。 这 了 两 次 请 
求 的 执行 过 程 ， 都 与 Docker 容 益 的 网 络 相 关 。 以 下 按照 这 两 个 请 求 的 
执行 ， 具 体 分 析 Docker 容 冀 网 络 的 创建 。Docker Daemon 如 何 通 
过 Docker Server 解 析 RESTful 请 求 ， 并 完成 路 由 ， 在 第 5 章 已 经 详 


细 分 析 过 ， 故 本 章 不 再 更 述 。 


7.4.1 创建 容 屁 之 网 络 配置 


Docker Daemon 创 建 容器 主要 执行 了 create container 操 作 。 


创建 容器 过 程 中 ，Docker Daemon 首 先 通过 runconfig 包 中 的 
ContainerConfigFromjob 盟 数 , 解析 出 请 求 中 的 config 对 象 ， 解 析 
过 程 代 码 如 下 : 


config := runconfig.ContainerConfigFromJob(job) 


至 此 ，Docker Client 处 理 得 到 的 config 对 象 , 已 经 传递 至 
Docker Daemon 的 config 对 象 ,config 对 象 中 已 经 含有 属性 
NetworkDisabled 的 具体 值 。 


而 容 状 创建 的 工作 内 容 主 要 有 以 下 两 点 : 
1) 创建 与 Docker 容 器 对 应 的 Container 类 型 实例 Container。 
2) 创建 Docker 容 器 的 rootfs。 


具体 的 源码 实现 位 
于 ./dockerdockerdaemon/create.go##L73-L78 ,如 下 所 示 : 


if container, err = daemon.newContainer(name, config, img); err != nil { 
return nil, nil, err 


if err := daemon.createRootfs(container, img); err != nil { 


return nil, nil, 


err 


与 Docker 容 需 网 络 模式 配置 相关 的 内 容 主 要 位 于 第 一 点 ， 即 创建 
container 实 例 中 。newContainer 贸 数 的 定义 位 
于 ./docker/docker/daemon/daemon.go#L516-L550 , 具体 的 


container 实 例如 下 : 


container := SContainert{ 


Created : 
Path : 

Args: 
Config: 
hostConfig: 
Image : 
NetworkSettings: 
Name: 
Driver: 
ExecDriver: 
State: 


id, 
time.Now() .UTC(), 
entrypoint, 
args, //FIXME: de-duplicate from config 
config, 
&runconfig.HostConfig{}, 
img.ID, // Always use the resolved image id 
&NetworkSettings{}, 
name, 
daemon.driver.String(), 
daemon.execDriver.Name(), 
NewState(), 


在 container 对 象 中 ，config 对 象 直接 赋值 给 container 对 象 的 
Config 属 性 ， 另 外 hostConfig 属 性 与 NetworkSettings 属 性 均 为 空 。 
其 中 hostConfig 对 象 将 在 start container 请 求 执行 过 程 中 被 赋值 ， 
NetworkSettings 类 型 的 作用 是 描述 容 疾 的 网 络 具 体 信息 , 定义 位 
于 ./docker/docker/daemon/network_settings.go#L11-L18 , 产 


码 如 下 所 示 : 


type NetworkSettings struct { 
IPAddress string 


IPPrefixLen int 


Gateway string 
Bridge string 
PortMapping map[string]PortMapping // Deprecated 


Po rts nat .PortMap 





Networksettings 类 型 的 各 属性 详细 说 明 如 表 7-3 所 示 。 


表 7-3 NetworkSettings 属 性 介绍 表 


























NetworkSettings 属性 名 称 类 型 含义 
IPAddress string 容器 网 络 接 口 的 IP 网 络 地 址 
IPPrefixLen int 网 络 标识 位 长 度 
Gateway string 容器 的 默认 网 关 地 址 
( 续 ) 
NetworkSettings 属性 名 称 类 型 含义 
Bridge string 容器 网 络 接口 使 用 的 网 桥 地 址 
PortMapping map[string]PortMapping 容器 与 宿主 机 的 端口 映射 
Ports nat.PortMap 容器 内 部 暴露 的 端口 号 


7.4.2 ”局 动容 希 之 网 络 配置 


创建 容器 阶段 ,， Docker Daemon 创 建 了 容器 对 象 Container ， 
container 对 象 内 部 的 Config 属 性 含有 NetworkDisabled。 创 建 容 妖 
完成 之 后 ,Docker Daemon 应 Docker Client 的 请 求 ， 需 要 执行 
create container 的 操作 。 这 部 分 的 执行 同样 需要 Docker Server 接 
收 请 求 ， 并 分 发 调度 处 理 。 


Docker Daemon 有 启动 容器 主要 执行 了 start container 操 作 。 


启动 容器 过 程 中 ，Docker Daemon 首 先 通过 runconfig 包 中 的 
ContainerHostConfigFromjob 上 纲 数 ， 解 析出 请 求 中 的 hostConfig 对 
象 ， 解 析 过 程 源码 如 下 : 


hostConfig := runconfig.ContainerHostConfigFromJob(job) 


至 此 ，Docker Client 处 理 得 到 的 hostConfig 对 象 ,已 经 传递 至 
Docker Daemon 的 hostConfig 对 象 ，hostConfig 对 象 中 已 经 含有 属 
性 NetworkMode 具 体 值 。 


容 希 局 动 的 所 有 工作 ， 均 由 以 下 Start 纹 数 来 完成 ， 源 码 位 
于 ./docker/docker/daemon/start.go#L36-L38 ,如 下 所 示 : 


if err := container.Start(); err != nil { 
return job.Errorf("Cannot start container %s: %s", name, err) 
} 


Start 咱 数 实现 了 容器 的 启动 。 更 为 具体 的 描述 是 : Start 组 数 实现 
了 进程 的 启动 ， 另 外 在 启动 进程 的 同时 为 进程 设 定 了 命名 空间 
( namespaces) 并 为 进程 做 了 资源 的 限制 ， 从 而 保证 进程 以 及 之 后 
进程 的 子 进程 都 会 在 相同 的 命名 空间 内 ， 且 受到 相同 的 资源 控制 。 如 
此 一 来 ，Start 组 数 创建 的 进程 ， 以 及 该 进程 之 后 的 子 进程 ， 形 成 一 个 
进程 组 ， 该 进程 组 处 于 资源 隔离 和 资源 控制 的 环境 中 ， 我 们 习惯 将 这 
样 的 进程 组 环境 称 为 容 右 ， 也 就 是 这 里 的 Docker 容 姨 。 


回 到 Start 多 数 的 执行 ， 位 
于 ./dockervdockerdaemon/containergo#L275-L320。Start 约 
数 的 执行 过 程 与 Docker 容 希 网 络 模式 相关 的 主要 有 三 部 分 : 


"initializeNetwork ,初始 化 container 对 象 中 与 网 络 相 关 的 属 
性 。 


:populateCommand , 填充 Docker 容 器 内 部 需要 执行 的 命令 ， 
Command 中 含有 进程 启动 命令 ， 还 含有 容 莫 环境 的 配置 信息 ,也 包 
括 网 络 配 症 。 


De 


-ContainerwaitForStart( ) ， 实现 Docker 容 器 内 部 进程 的 启 
动 ， 进 程 局 动 之 后 ， 为 容 右 创建 网 络 环 境 等 。 


1. 初 始 化 容 颖 网 络 配置 


容器 对 象 cContainer 中 有 属性 hostConfig， 属 性 hostConfig 中 有 
属性 NetworkMode , 初始 化 容器 网 络 配置 initializeNetworking( ) 
的 主要 工作 就 是 : 通过 NetworkMode 属 性 为 Docker 容 兹 的 网 络 做 相 
应 的 初始 化 配置 工作 。 


Docker Container 的 网 络 模式 有 四 种 ， 分 别 为 : host、other 
container、none 以 及 bridge。initializeNetworking 员 数 的 执行 完 
全 禾 荔 了 这 四 种 模式 。 


initializeNetworking( ) 函数 的 源码 实现 位 
于 ./docker/docker/daemon/container.go#L881-L933 ,如 下 所 


小 ， 


func (container *Container) initiaLizeNetworking() error { 

var err error 

if container.hostConfig.NetworkMode.IsHost() { 
container.Config.Hostname, err = os.Hostname() 


if err != nil { 
return err 
} 
parts := strings.SplitN(container.Config.Hostname, ".", 2) 


if len(parts) > 1 { 
container.Config.Hostname = parts[0] 
container.Config.Domainname = parts[1] 
} 
content, err := ioutil.ReadFile("/etc/hosts") 
If os.IsNotExist(err) { 
return container.buildHostnameAndHostsFiles("") 
} else if err != nil { 
return err 
} 


if err := container.buildHostnameFile(); err != nil { 
return err 


} 
hostsPath, err := container.getRootResourcePath("hosts") 
if err != nil { 

return err 


} 

container.HostsPath = hostsPath 

return ioutil.WriteFile(container.HostsPath, content, 0644) 
} else if container.hostConfig.NetworkMode.IsContainer() { 

// we need to get the hosts files from the container to join 


nc, err := container.getNetworkedContainer() 
if err != nil { 
return err 


container.HostsPath = nc.HostsPath 
container.ResolvConfPath = nc.ResolvConfPath 
container.Config.Hostname = nc.Config.Hostname 
container.Config.Domainname = nc.Config.Domainname 

} else if container.daemon.config.DisableNetwork { 
container.Config.NetworkDisabled = true 
return container.buildHostnameAndHostsFiles("127.0.1.1") 


} else { 
if err := container.allocateNetwork(); err != nil { 
return err 
} 
return 


container.buildHostnameAndHostsFiles(container.NetworkSettings.IPAddress) 


return nil 


针对 以 上 源码 ， 下面 以 4 种 不 同 的 网 络 模 式 分 析 
initializeNetworking 喘 数 的 作用 。 


第 一 ，host 网 络 模式 。Docker 容 器 网 络 的 host 模 式 意味 着 容器 使 
用 宿主 机 的 网 络 环境 。 虽 然 Docker 容 器 使 用 宿主 机 的 网 络 环境 ， 但 这 
并 不 代表 Docker 容 絮 可 以 拥有 宿主 机 文件 系统 的 视角 ， 而 host 答 主机 
上 有 很 多 信息 标识 的 是 网 络 信息 , 故 Docker Daemon 需 要 将 这 部 分 
标识 网 络 的 信息 ， 从 宿主 机 上 添加 到 Docker 容 器 内 部 的 指定 位 置 。 这 
样 的 网 络 信息 ， 主 要 有 以 下 三 种 : 


` 答 主机 的 hostname 文 件 ， 代表 容 闫 的 主机 名 。 


- 答 主 机 的 hosts 文 件 ， 代 表 容 兹 的 主机 名 配置 文件 。 


: 答 主 机 resolv.conf 文 件 ， ， 属 于 容 关 的 域名 文件 。 


由 于 Docker 容 怖 与 和 主 机 共享 网 络 ， 因 此 Docker 容 希 的 
hostname 文 件 、hosts 文 件 以 及 resolv.conf 文 件 原则 上 与 宿主 机 上 
的 这 些 文件 内 容 应 该 保持 一 致 。 结 果 就 是 : Docker Daemon 将 答 主 
机 的 hostname 文 件 、hosts 文 件 以 及 resolv.conf 内 容 写 入 Docker 容 
怖 的 指定 目录 下 。 目录 一 般 
为 /var/lib/docker/containers/< container id> , 当 容 器 局 动 时 ， 
再 将 这 部 分 文件 挂 载 进 容 钴 内 部 的 指定 路 径 。 


第 二 ,other container 网 络 模式 。Docker 容 器 的 other 
container 网 络 模 式 意味 着 : 容 兹 使 用 其 他 已 经 创建 容 痪 的 网 络 环境 。 


Docker Daemon 首 先 判断 host 网 络 模式 ， 知 不 为 host 网 络 模 
式 ， 则 继续 判断 是 否 为 other container 模 式 。 若 Docker 容 器 的 网 络 
模式 为 other container( 假设 使 用 的 -net 参 数 为 --net= container : 
17adef , 其 中 17adef 为 容器 ID) ， 则 用 户 必 须 指定 被 共享 网 络 的 
Docker 容 右 ， 此 处 容 右 ID 为 17adef。 在 这 种 情况 下 ，Docker 
Daemon 所 做 的 执行 操作 包括 两 步 。 


第 一 步 ， 从 container 对 象 的 hostConfig 属 性 中 找 出 
NetworkMode ，, 并 找到 相应 的 容 左 ， 即 17adef 的 容 怖 对 象 
container ,实现 源码 如 下 : 


nc, err := container.getNetworkedContainer() 


第 二 步 ， 将 17adef 容 器 对 象 的 HostsPath、ResolveConfPath、 
Hostname 和 Domainname 赋 值 给 当前 容器 对 象 Container , 实现 源 


码 如 下 : 


container.HostsPath = nc.HostsPath 
container.ResolvConfPath = nc.ResolvConfPath 
container.Config,.Hostname = nc.Config.Hostname 
container.Config.Domainname = nc.Config.Domainname 


第 三 , none 网 络 模式 。Docker 容 器 的 none 网 络 模 式 意 味 着 不 给 
该 容器 创建 任何 网 络 环境 ， 容 右 只 能 使 用 127 .0.1.1 的 环 回 接口 。 


Docker Daemon 通 过 config 属 性 的 DisableNetwork 来 判断 是 
否 为 none 网 络 模式 。 实 现 源码 如 下 : 


if container.daemon.config.DisableNetwork { 
container.Config.NetworkDisabled = true 
return container.buildHostnameAndHostsFiles("127.0.1.1") 


} 


第 四 ，bridge 网 络 模 式 。Docker 容 器 的 bridge 网 络 模式 意味 着 
为 容 希 创建 桥接 网 络 模式 。 桥 接 模式 使 得 Docker 容 痪 创建 独立 的 网 络 
环境 ， 并 通过 “桥接 "的 方式 实现 Docker 容 器 与 外 界 的 网 络 通信 。 


初始 化 bridge 网 络 模式 的 配置 ， 实 现 源码 如 下 : 


if err := container.allocateNetwork(); err != nil { 
return err 


return container.buildHostnameAndHostsFiles(container.NetworkSettings.IPAddress) 


以 上 代码 完成 的 内 容 主要 也 是 两 部 分 : 第 一 ， 通 过 
allocateNetwork 钢 数 为 容 需 分 配 一 个 网 络 接口 可 用 的 IP 地 址 ， 并 将 
网 络 配置 ( 包括 IP、bridge、Gateway 等 ) 赋值 给 container 对 象 的 
NetworkSettings ; 第 二 ,通过 NetworkSettings 为 容 姨 创建 
hosts、hostname 等 文件 。 


2 .创建 容 器 Command 信 息 


Docker 在 实现 容 需 时 ， 在 源码 层次 使 用 Command 类 型 。 
Command 是 一 个 非常 重要 的 概念 ， 我们 可 以 认为 Command 类 型 包 
含 了 两 部 分 的 内 容 : 第 一 ， 和 运行 容 希 内 进程 的 外 部 命令 exec.Cmd ; 
第 二 ， 运行 容 间 时 启动 进程 需要 的 所 有 基础 信息 : 包括 容 疮 进程 组 的 
使 用 资源 、 网 络 资源 、 使 用 设备 、 工 作 路 径 等 。 通 过 这 两 部 分 的 内 
容 ， 我 们 清楚 如 何 创建 容 希 内 的 进程 ， 同 时 也 清楚 为 容 凑 创 建 什么 样 
的 环境 。 


首先 ， 我 们 先 来 看 Command 类 型 的 定义 ,位 
于 ./docker/docker/daemon/execdriver/driver.go#L84。 通 过 分 
析 Command 类 型 以 及 相关 的 其 他 数据 结构 类 型 ， 得 到 的 Command 
类 型 天 系 如 图 7-7 所 示 。 






Command 
String 
Privileged bool Network 


User string 


Rootfs string Interface *NetworkInterface NetworkInterface 
InitPath Mtu 
ate ay stri i 





string Lnt 

bntrypoint string ContainerTD String 

Arguments [string HostNetworking bool 

WorkingDir string 
string IPPrefixLen int 
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*Network 


*Resources int64 
[JMount ， VSWan int64 
AllowedDevices ‘puShares int64 
| J*devices, Device 
AutoCreatedDevices 
[J*devices. Device 


string 


r] 
lJstring 


Mount 


Terminal 
string 


. a Source string 
ContainerPid int 


图 7-7 ” Command 类 型 关系 图 


从 Command 类 型 天 系 图 中 ,我 们 可 以 看 到 Command 类 型 中 第 
一 个 属性 为 exec.Cmd , 即 代表 需要 创建 的 进程 具体 的 外 部 命令 ; 同 
时 ， 关于 网 络 方面 的 属性 有 Network , Network 的 类 型 为 
*Network ; 关于 Docker 容 器 资源 使 用 方面 的 属性 为 Resources ,从 
Resource 的 类 型 来 看 , Docker 自 前 能 做 的 资源 限制 有 4 个 维度 ， 分 别 
为 内 存 ， 内 存 +Swap， CPU 使 用 ,CPU 核 使 用 ; 关于 挂 载 的 内 容 , 有 
属性 Mounts ; 等 等 。 


简单 介绍 Command 类 型 之 后 , 回 到 Docker Daemon 局 动容 砂 


网 络 的 源码 分 析 。 紧 接 在 消 数 initializeNetworking 之 后 , 是 


populateCommand 环 节 。populateCommand 的 函数 实现 位 

于 ./docker/docker/daemon/container.go#L191-L274。 上 文 已 经 
提 及 ,populateCcommand 的 作用 是 创建 execdriver 包 中 的 对 象 
command 实 例 , 该 Command 中 既 有 局 动容 怖 进程 的 外 部 命令 , 同 
时 也 有 众多 容 需 环境 的 配置 信息 ， 包 括 网 络 。 


本 小 节 ， 分 析 populateCommand 如 何 填充 Command 对 象 中 的 
网 络 信息 ， 其 他 内 容 的 分 析 会 在 第 12 章 和 第 13 章 进行 展开 。 


Docker 容 左 有 四 种 网 络 模式 ， 故 populateCommand 首 先 需 
判断 容 大 属于 哪 种 网 络 模式 ， 随 后 将 具体 的 网 络 模式 信息 ， 写 入 
Command 对 象 的 Network 属 性 中 。 查 验 Docker 容 匡 网 络 模式 的 源码 
位 于 ./docker/docker/daemon/container.go#L204-L227 , 如 下 所 


小 : 


parts := strings.SplitN(string(c.hostConfig.NetworkMode), ":", 2) 
Switch parts[0] { 
case "none": 
case "host": 
en.HostNetworking = true 
case "bridge", "": // empty string to support existing containers 
if !c.Config.NetworkDisabled { 
network := c.NetworkSettings 
en.Interface = Sexecdriver.NetworkInterfacet 
Gateway: network.Gateway, 
Bridge: network.Bridge, 
IPAddress : network.IPAddress， 
IPPrefixLen: network.IPPrefixLen, 
} 
} 
case "container": 
nc, err := c.getNetworkedContainer() 
if err != nil { 
return err 


} 
en.ContainerID = nc.ID 
default: 


return fmt.Errorf("invalid network mode: %s", c.hostConfig.NetworkMode) 


} 


populateCommand 首 先 通过 hostConfig 对 象 中 的 
NetworkMode 判 断 容 肴 属于 哪 种 网 络 模式 。 该 部 分 内 容 涉及 
execdriver 包 中 的 Network ,可 参见 Command 类 型 关系 图 中 的 
Network 类 型 。 若 为 none 模 式 ， 则 对 于 Network 对 象 ( 即 en ， 
*execdriver.Network) 不 做 任何 操作 。 大 为 host 模 式 ， 则 将 
Network 对 和 象 的 HostNetworking 置 为 true ; 若 为 bridge 桥 接 模 式 ， 
则 首先 创建 一 个 Networklnterface 对 象 ， 完 善 该 对 象 的 Gateway、 
Bridge、IPAddress 和 IPPrefixLen 信 息 ,最 后 将 Networklnterface 
对 象 作 为 Network 对 象 的 中 Interface 属 性 的 值 ; 若 为 other 
container 模 式 ， 则 首先 通过 getNetworkedContainer( ) 函数 获知 
被 分 扣 网 络 命名 空间 的 容 闫 ， 最 后 将 容 关 ID ,赋值 给 Network 对 象 的 
ContainerID。 由 于 bridge 模 式 、host 模 式 以 及 other container 模 
式 彼此 互 斥 , 故 Network 对 象 中 Interface 属 性 、ContainerID 属 性 以 
及 HostNetworking 三 者 之 中 只 有 一 个 被 赋值 。 当 Docker 容 部 的 网 络 
被 查验 之 后 , populateCommand 将 en 实例 Network 属 性 的 值 , 传 
递 给 Command 对 象 。 


3. 局 动容 闫 内 部 进程 


当 为 容器 做 好 所 有 的 配置 之 后 ,Docker Daemon 需 要 真正 意义 
上 的 启动 容器 。 根 据 启动 容 匡 流程 中 涉及 的 Docker 模 块 ，Docker 


Daemon 后 续 环 节 中 实现 启动 容器 的 请 求 会 被 发 送 至 execdriver , 再 
经 过 libcontainer , 最 后 实现 Linux 内 核 级 别 的 进程 启动 。 


回 到 Docker Daemon 的 启动 容 右 ，daemon 包 中 start 员 数 的 最 
后 一 步 即 为 执行 Container.waitForStart( ) 。waitForStart 钢 数 的 
定义 位 于 ./docker/daemon/container.go#L107 0-L1082， 源码 如 
下 : 


func (container *Container) waitForStart() error { 
container.monitor = newContainerMonitor(container， 
container.hostConfig.RestartPolicy) 
select { 
case <-container.monitor.startSignal: 
case err := <-utils.Go(container.monitor.Start): 
return err 


return nil 


以 上 源码 运行 过 程 中 ，Docker Daemon 首先 通过 男 数 
newContainerMonitor 返 回 一 个 初始 化 的 containerMonitor 对 象 ， 
该 对 象 中 带 有 容器 进程 的 重 局 策略 。 总 体 而 言 ，ContainerMonitor 对 
象 用 以 监视 容器 进程 的 执行 。 容 器 进程 指 的 是 容器 pid namespace 内 
进程 号 为 1 的 进程 ， 这 个 进程 的 状态 代表 容 右 的 状态 。 一 旦 该 进程 停止 
运行 ， 则 容器 内 部 所 有 进程 都 将 收 到 一 个 终止 信号 ， 最 终 导致 容器 的 
运行 失败 。 如 果 containerMonitor 中 指定 了 进程 的 重 局 策略 ， 那 儿 
旦 容 疹 进 程 没有 局 动 成 功 ，Docker Daemon 会 使 用 重 局 策略 来 重 局 
容器 。 如 果 在 重启 策略 下 ， 容 次 依然 没有 成 功 启 动 ， 那 么 
containerMonitor 对 象 会 负责 重 置 以 及 清除 所 有 已 经 为 容器 准备 好 的 


资源 , 例如 已 经 为 容器 分 配 好 的 网 络 资 源 ( 即 IP 地 址 ) ， 还 有 为 容 闫 
准备 的 rootfs 等 。 


Da OO 


waitForStart( ) 函数 通过 containermonitor.Start 来 实现 容器 
的 启动， 进入 ./dockerdockerdaemon/monitorgo##LL100 , 可 以 
发 现 启 动容 兹 进程 位 
于 ./dockervdockerdaemon/monitorgo#L136 ,源码 如 下 : 


exitStatus, err = m.container.daemon.Run(m.container, pipes, m.callback) 


以 上 源码 实际 调用 了 daemon 包 中 的 Run 函 数 ,位 
于 ./docker/daemon/daemon.go#L969-L971 , 如 下 所 示 : 


func (daemon *Daemon) Run(c *Container, pipes *execdriver.Pipes, startCallback 
execdriver.StartCallback) (int, error) { 

return daemon.execDriver.Run(c.command, pipes, startCallback) 
} 


最 终 ，Run 也 数 中 调用 了 execdriver 中 的 Run 函 数 来 执行 Docker 
Container 的 启动 命令 。 


至 此 ， 网 络 部 分 在 Docker Daemon 内 部 的 执行 已 经 结束 ， 紧 接 
着 程序 的 运行 陷入 execdriver , 进一步 运行 容 背 局 动 的 相关 步 又 。 


7.5 execdriver 网 络 执行 流程 


Docker 染 构 中 execdriver 的 作用 是 启动 容 兹 内 部 进程 ， 最 终局 动 
容 希 。 目 前， 在 Docker 中 execdriver 作 为 执行 驱动 ， 可 以 有 两 种 选 
项 : |xc 与 native。 其 中 ，|Xc 驱 动 会 调用 |xc 工 具 实 现 容 问 的 局 动 ， 而 
native 驱 动 会 使 用 Docker 官 方 发 布 的 libcontainer 来 局 动容 莓 。 


Docker Daemon 启 动 过 程 中 ，execdriver 的 类 型 默认 为 
native， 故 本 章 主要 分 析 native 驱 动 在 执行 局 动容 莫 时 ， 如何 处 理 网 
络 部 分 。 


在 Docker Daemon 启 动容 器 的 最 后 一 步 ， 即 调用 了 execdriver 
的 Run 函 数 来 执行 。 通 过 分 析 Run 函 数 的 具体 实现 ， 可知 关于 Docker 
容器 的 网 络 执行 流程 主要 包括 两 个 环节 : 


1) 创建 libcontainer 的 Config 对 象 。 
2) 通过 libcontainer 中 的 namespaces 包 执行 启动 容器 。 


将 execdriverRun 因 数 的 运行 流程 展开 ,与 Docker 容 顺 网 络 相 
关 的 流程 7 如 图 7-8 所 示 。 
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template. New () 
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| | 
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Docke r Daemon 启 动 容 吕 


namespaces. Exec 


execdriver 启 动容 器 


图 7-8 execdriverRun 执 行 流程 图 





7.5.1 创建 libcontainer 的 Config 对 象 


Run 蝎 数位 
于 ./docker/docker/daemon/execdriver/native/driver.go#L62- 
L168。 进 入 Run 喘 数 的 实现 ,立即 可 以 发 现 该 函数 通过 
createContainer 创 建 了 一 个 container 对 象 ， 源 码 如 下 : 


container, err := d.createContainer(c) 


其 中 c 为 Docker Daemon 创 建 的 execdriver.Command 类 型 实 
例 。 以 上 源码 中 createContainer 缠 数 的 作用 是 : 使 用 
execdriver.Command 来 填充 libcontainer.Config。 简 要 介绍 
libcontainer.Config 的 作用 就 是 ， 它 定义 了 在 一 个 容 莫 化 的 环境 中 执 
行 一 个 进程 所 需要 的 所 有 配置 项 。createContainen 六 数 使 用 Docker 
Daemon 层 创建 的 execdriver.Command , 创建 更 底层 libcontainer 
所 需要 的 Config 对 象 。 从 这 个 角度 来 看 , execdriver 更 像 是 封装 了 
libcontainer 对 外 的 接口 ， 实现 了 将 Docker Daemon 特 有 的 容器 启 
动 信息 转换 为 底层 libcontainer 能 真正 使 用 的 容器 配置 选项 。 
libcontainer.Config 类 型 与 其 内 部 对 象 之 间 的 关系 如 图 7-9 所 示 。 


createContainer 的 源码 实现 部 分 位 


于 ./docker/docker/daemon/execdriver/native/create.go#L23- 


L77， 如 下 所 未 : 





func (d *driver) createContainer(c *execdriver.Command) (*libcontainer.Config, 
error) { 
container := tempLate.New() 


if err := d.createNetwork(container, c); err != nil { 
return nil, err 
} 


return container, nil 









Type string MountConfig  *#¥MountConfig NoPivotRoot bool 
NsPath string Hostname string ReadonlyFs bool 
Bridge string User string Mounts Mounts 
VethPrefix string WorkingDir string DeviceNodes [|]*devices. Device 
Address string Enyv [J] string MountLabel string 
Gateway string Tty bool 
Mtu int Namespaces map[stringjbool 
Capabilities [|]string 
Networks []*Network 
Routes []*Route 
Cgroups 条 cgFOUDS. Cgroup 
AppArmorProfile string 
my St Et ng ProcessLabel string 
Parent string RestrictSys bool Destination 


Writable bool 
AllowAllDevices bool Relabe] string 


AllowedDevices []*devices, Device boai 
Memory int64 
MemoryReservation int64 
MemorySwap int6d 
CpuShares int64 
CpuQuota int6d 
CpuPeriod int64 
CpusetCpus string 
FreezerState 
string 


Destination string 
Source string 


Gateway string 
InterfaceName string 


图 7-9 libcontainerConfig 类 型 关系 图 
1.libcontainer.Config 模 板 实例 


从 createContainer 溪 数 的 实现 以 及 execdriver.Run 执 行 流程 图 
中 都 可 以 看 到 ，create-Container 所 做 的 第 一 个 操作 就 是 执行 


template.New( ) ， 意 为 创建 一 个 libcontainerConfig 的 实例 容 
器 。 其 中 ,template.New( ) 的 定义 位 


于 ./docker/docker/daemon/execdriver/native/template/defaul 
t template.go， 主 要 的 作用 为 返回 libcontainer 关 于 Docker 容 闫 的 
默认 配置 选项 。 


Template.New( ) 的 源码 实现 如 下 : 


func New() *Libcontainer.Config { 
container := &libcontainer.Config{ 

Capabilities: []string{ 
"CHOWN", 

"DAC OVERRIDE", 
"FSETID", 
"FOWNER", 
"MKNOD", 

"NET_ RAW", 
"SETGID", 
"SETUID", 
"SETFCAP", 
"SETPCAP", 
"NET_ BIND SERVICE", 
"SYS CHROOT®", 
"KILL", 

"AUDIT WRITE", 

}, 

Namespaces: map[stringl]boolt{ 
"NEWNS": true, 
"NEWUTS": true, 
"NEWIPC": true, 
"NEWPID": true, 
"NEWNET": true, 


}, 
Cgroups: &cgroups.Cgroupt{ 
Parent: "docker", 
AllowAllDevices: false, 
}, 
MountConfig: &libcontainer.MountConfig{}, 
} 
if apparmor.IsEnabled() { 
container.AppArmorProfile = "docker-default" 
} 


return container 


libcontainerConfig 默 认 的 模板 对 象 ， 首 先 设 定 了 Capabilities 
的 默认 项 ,如 CHOWN、DAC OVERRIDE、FSETID 等 ; 其 次 又 为 
Docker 容 希 所 需 设 定 的 namespaces 添 加 默认 值 ， 即 需要 创建 5 个 命 
名 空间 , 如 NEWNS、NEWUTS、NEWIPC、NEWPID 和 NEWNET ， 
其 中 不 包括 user namespace ， 另 外 与 网 络 相 关 的 namespace 是 
NEWNET ; 最 后 设 定 了 一 些 天 于 cgroup 以 及 apparmor 的 默认 配置 。 


Template.New( ) 函数 最 后 返回 类 型 为 libcontainerConfig 的 
实例 container ,该 实例 中 只 包含 默认 配置 项 ， 其 他 内 容 的 添加 需要 
createContainer 的 后 续 代 码 来 完成 。 


2.createNetwork 实 现 


在 createContainer 的 实现 流程 中 ,为 了 完善 Container 对 象 ( 类 
型 为 libcontainerConfig) ， 后 续 还 有 很 多 步 又， 如 与 网 络 相关 的 
createNetwork 贸 数 调用 ,与 Linux 内 核 Capabilities 相 关 的 
setCapabilities 允 数 调用 ,与 cgroups 相 关 的 setupCgroups 男 数 调 
用 ， 以 及 与 挂 载 目 录 相关 的 SetupMounts 销 数 调用 等 。 本 小 节 主 要 分 
析 createNetwork 绥 数 如 何 为 Container 对 象 完善 网 络 配置 项 。 


createNetwork 久 数 的 定义 位 
于 ./docker/docker/daemon/execdriver/native/create.go#L79- 


L124 ,该 函数 主要 利用 execdriverCommand 中 Network 属 性 的 内 


容 ， 来 判断 如 何 创建 libcontainer.Config 中 的 Network 属 性 ( 关于 两 
种 Network 属 性 ,可 以 参见 图 7-7 和 图 7-9) 。 由 于 Docker 容 器 的 4 种 
网 络 模式 彼此 互 斥 , 故 以 上 Network 类 型 中 Interface、ContainerID 
与 HostNetworking 最 多 只 有 一 项 会 被 赋值 。 


execdriver.Command 中 Network 的 类 型 定义 如 下 : 


type Network struct { 


Interface *+NetworkInterface 
Mtu int 
ContainerID string 


HostNetworking bool 
} 


在 以 上 Network 类 型 的 基础 上 ,我们 分 析 createNetwork 色 数 ， 
其 具体 实现 可 以 归纳 为 以 下 4 个 部 分 : 


1) 判断 网 络 是 否 为 host 模 式 。 

2) 判断 网 络 是 否 为 bridge 桥 接 模式 。 

3) 判断 网 络 是 否 为 other container 模 式 。 
4) 为 Docker 容 器 添加 |oopback 网 络 设备 。 


首先 ， 我 们 来 看 execdriver 判 断 容 器 网 络 是 人 否 为 host 模 式 的 源 
位 : 


if c.Network.HostNetworking { 
container.Namespaces["NEWNET"] = false 


return nil 


当 execdriverCommand 类 型 实例 中 Network 属 性 的 
HostNetworking 为 true , 则 说 明 需 要 为 Docker 容 姻 创 建 host 网 络 模 
式 ， 使 容 硕 与 稍 主 机 共享 相同 的 网 络 命名 空间 。 在 host 模 式 的 具体 介 
绍 中 ， 我 们 已 经 前 明 , 只 要 Docker Daemon 在 创建 容 妖 进程 ， 进 行 
CLONE 系 统 调用 时 ， 不 传 入 CLONE_NEWNET 参 数 标志 即 可 实现 共享 
网 络 命名 空间 。 这 部 分 源码 正好 准确 地 验证 了 这 一 点 。Docker 
Daemon 将 container 对 象 中 代表 网 络 命名 空间 的 NEWNET 设 为 
false , 最 终 导 致 libcontainer 中 不 创建 新 的 网 络 命名 空间 。 


骨 来 看 ,execdriver 判 断 容器 网 络 是 否 为 bridge 桥 接 模式 的 源 
但 : 


if c.Network.Interface != nil { 
vethNetwork := libcontainer.Networkt{ 
Mtu: c.Network.Mtu, 
Address: fmt.Sprintf("%s/%d", c.Network.Interface.IPAddress, 
c.Network.Interface.IPPrefixLen), 
Gateway: c.Network.Interface.Gateway, 
Type: "veth", 
Bridge: c.Network.Interface.Bridge, 
VethPrefix: "veth", 


container.Networks = append(container.Networks, &vethNetwork) 


} 


当 execdriverCommand 类 型 实例 中 Network 属 性 的 Interface 
不 为 nil 值 ， 则 说 明 需 要 为 Docker 容 器 创建 bridge 桥 接 模式 ， 使 容器 
拥有 隔离 的 网 络 环境 。 于是， 以 上 源码 为 libcontainer.Config 的 


container 对 象 添加 Networks 属 性 vethNetwork ,网 络 接口 类 型 为 
veth ， 以 便 libcontainer 在 执行 时 ， 可 以 为 Docker 容 器 创建 veth 


pair, 


接着 来 看 eXxecdriver 判 断 容 器 网 络 是 否 为 other container 模 式 
的 代码 : 


If c.Network.ContainerID != "" { 
d.Lock() 
active := d.activeContainers[c.Network.ContainerID] 
d.Unlock() 
if active == nil || active.cmd.Process == niL { 


return fmt.Errorf("%s is not a valid running container to join", 
c.Network.ContainerID) 


cmd := active.cmd 
nspath := filepath.Join("/proc", fmt.Sprint(cmd.Process.Pid), "ns", "net") 
container.Networks = append(container.Networks, Slibcontainer.Network{ 
Type: "netns", 
NsPath: nspath, 
}) 


当 execdriverCommand 类 型 实例 中 Network 属 性 的 
ContainerID 不 为 空 字符 串 时 ， 则 说 明 需 要 为 Docker 容 器 创建 other 
container 模 式 ， 使 创建 容 郑 共享 其 他 容 屁 的 网 络 环境 。 实 现 过 程 中 ， 
execdriver 首 先 需 要 在 activeContainers 中 查找 需要 被 共享 网 络 环境 
的 容 右 active ; 并 通过 active 容 器 的 月 动 执行 命令 cmd 找 到 容器 主 进 
程 在 宿主 机 上 的 PID ; 随后 在 proc 文 件 系 统 中 找到 该 进程 PID 的 关于 网 
络 命名 空间 的 路 径 nspath ,也 是 整个 容 莫 的 网 络 命 名 空间 路 径 ; 最 后 
为 类 型 为 libcontainer.Config 的 container 对 象 添 加 Networks 属 性 ， 


Network 的 类 型 为 netns。 


此 外 ，createNetwork 钥 数 还 实现 了 为 Docker 容 器 创建 一 个 
loopback 环 回 接 月， 以 便 容 背 可 以 实现 内 部 通信 。 实 现 过 程 中 ,同样 
为 类 型 libcontainerConfig 的 container 对 象 添加 Networks 属 性 ， 
Network 的 类 型 为 Joopback ,源码 如 下 : 


container.Networks = []*libcontainer.Network{ 
{ 


Mtu: c.Network.Mtu, 
Address: fmt.Sprintf("%s/%d", "127.0.0.1", 0), 
Gateway: "localhost", 
Type: "loopback", 
}, 
} 


至 此 ,createNetwork 级 数 已 经 把 与 网 络 相关 的 配置 ， 全 部 创建 
在 类 型 为 libcontainer.Config 的 container 对 象 中 ， 随 时 等 候 创 建 容 
妖 进 程 的 来 临 。 


7.5.2 调用 libcontainer 的 Namespaces 启 动 


OO 


~ 


合 


回 到 execdriverRun 上 级 数 ， 创 建 完 libcontainerConfig 实 例 
container , 经 过 一 系列 处 理 之 后 ， 最 终 execdriver 执 行 
namespaces.Exec 哨 数 实现 启动 容器 。 启 动 过 程 中 container 对 和 象 
依然 是 namespace.Exec 明 数 中 一 个 非常 重要 的 参数 。 
namespaces.Exec 代 表 着 execdriver 把 启动 Docker 容 器 的 工作 交 
给 libcontainer , 之 后 的 程序 执行 将 完全 陷入 libcontainer。 


调用 namespaces.Exec 的 源码 位 
于 ./docker/daemon/execdriver/native/driver.go#L102-L127 ， 
为 了 便于 理解 ， 简 化 之 后 如 下 : 


namespaces.Exec(container, c.Stdin, c.Stdout, c.Stderr, c.Console, c.Rootfs, 
dataPath, args, parameter 1, parameter 2) 


其 中 parameter 1 为 定义 的 函数 ， 如 下 所 示 : 


func(container *libcontainer.Config, console, rootfs, dataPath, init string, 
child *os.File, args []string) *exec.Cmd { 
c.Path = d.initPath 
c.Args = append([]string{ 
DriverName, 
"-console", console, 
"-pipe", "3", 
"-root", filepath.Join(d.root, c.ID), 


}, args...) 
// set this to nil so that when we set the clone flags anything else is 
reset 
c.SysProcAttr = &syscall.SysProcAttr{ 
Cloneflags: 
uintptr(namespaces.GetNamespaceFlags (container.Namespaces)), 


c.ExtraFiles = []*os.File{child} 
Cc.Env container.Env 

c.Dir c.Rootfs 

return &c.Cmd 


同样 ,parameter_2 也 为 定义 的 函数 ， 如 下 所 示 : 


func() { 
if startCallback != nil { 
c.ContainerPid = c.Process.Pid 
startCallback(c) 


parameter 1 以 及 parameter 2 这 两 个 曙 数 均 会 在 
libcontainer 的 namespaces 中 发 挥 很 大 的 作用 ,7.6 节 将 进行 深入 
分 析 。 


至 此 ,execdriver 模 块 的 执行 部 分 已 经 结束 , Docker Daemon 


的 运行 陷入 libcontainer。 


7.6 libcontainer 实 现 内 核 态 网 络 配置 


libcontainer 是 一 个 Linux 操 作 系统 上 容 闫 技术 的 解决 方案 。 
libcontainer 指 定 了 创建 一 个 容 怖 时 所 需要 的 配置 选项 ， 同 时 它 利 用 
Linux 中 namespaces 和 cgroups 等 技术 为 使 用 者 提供 了 一 套 Golang 
原生 态 的 容器 实现 方案 ， 并 且 没 有 使 用 任何 外 部 依赖 。 用 户 借助 
libcontainer , 可 以 感受 到 众多 操作 命名 空间 、 网 络 等 资源 的 便利 。 


当 execdriveri 诗 用 libcontainer 中 namespaces 包 的 EXxec 贤 数 
时 , libcontainer 开 始 发 挥 其 实现 容 希 功能 的 作用 。Exec 冰 数位 
于 ./docker/libcontainer/namespaces/exec.go#L24-L113。 本 
节 更 多 地 关心 Docker 容 器 的 网 络 创 建 ， 因 此 从 这 个 角度 来 看 Exec 的 
实现 可 以 分 为 三 个 步骤 : 


1) 通过 createCommand 创 建 一 个 Golang 语 言 内 的 exec.Cmd 
对 象 。 


2) 启动 命令 exec.Cmd , 创建 容器 内 的 第 一 个 进程 。 


3) 通过 InitializeNetworking 卫 数 为 容器 进程 初始 化 网 络 环 


以 下 从 源码 实现 的 角度 ， 详 细 分 析 这 三 个 部 分 。 


7.6.1 创建 exec.Cmd 


提 到 exec.Cmd ，, 就 不 得 不 提 Go 语 言 标 准 库 中 的 0s 包 和 os/exec 
包 。 前 者 提供 了 与 平台 无 关 的 操作 系统 功能 集 ， 后 者 则 提供 了 功能 
里 与 命令 执行 相关 的 部 分 。 


首先 来 看 一 下 在 Go 语言 中 exec.Cmd 的 定义 ， 如 下 所 示 : 


type Cmd struct { 


Path string // 所 需 执行 命令 在 系统 中 的 路 径 
Args []string // 传 入 命令 的 参数 

Env []string // 进 程 运 行 时 的 环境 变量 

Dir string // 命 令 运 行 的 工作 目录 


Stdin io.Reader 
Stdout io.Writer 
Stderr io.Writer 





ExtraFiles []*os.File // 进 程 所 需 打 开 的 额外 文件 

SysProcAttr *syscall.SysProcAttr  ”// 可 选 的 操作 系统 属性 

Process *0s.Process // 代 表 Cmd 启 动 后 ,操作 系统 底层 的 具体 进程 
ProcessState *os,ProcessState // 进 程 退出 后 保留 的 信息 


清楚 Cmd 的 定义 之 后 ， 再 来 分 析 namespaces 包 中 的 Exec 少 
数 ，libcontainer 是 如 何 来 创建 exec.Cmd 的 。 在 Exec 疯 数 的 实现 过 
程 中 ， 使 用 了 以 下 源码 实现 Exec.Cmd 的 创建 : 


command := createCommand(container, console, rootfs, dataPath, os.Args[0], 
syncPipe.Child(), args) 


其 中 createCommand 为 namespace.Exec 国 数 中 传 入 的 倒数 


第 二 个 参数 ， 类 型 为 CreateCommand。 而 createCommand 只 是 


namespaces.EXxec 久 数 的 形 参 ， 真 正 的 实 参 则 为 execdriveri 诗 用 


namespaces.Exec 时 的 参数 parameter 1 ,源码 如 下 : 


func(container *libcontainer.Config, console, rootfs, dataPath, init string, 
child *os.File, args []string) *exec.Cmd { 

c.Path = d.initPath 

c.Args = append([]string{ 


DriverName, 
"-console", console, 
"-pipe", 3 
"-root", filepath.Join(d.root, c.I1D), 
}, args...) 
// set this to nil so that when we set the clone flags anything else is 
reset 
c.SysProcAttr = &syscall.SysProcAttr{ 
Cloneflags: 


uintptr(namespaces.GetNamespaceFlags (container.Namespaces)), 
} 


c.ExtraFiles = []*os.File{child} 
c.Env = container.Env 

c.Dir = c.Rootfs 

return &c.Cmd 


熟悉 exec.Cmd 的 定义 之 后 ， 分 析 以 上 源码 就 显得 较为 简单 。 为 
Cmd 赋 值 的 对 象 有 Path、Args、SysProcAttr、ExtraFiles、Env 和 
Dir。 其 中 需要 特别 注意 的 是 Path 的 值 d.initPath , 该 路 径 下 存放 的 是 
dockerinit 的 二 进 制 文 件 , Docker 1.2.0 版 本 下 ,路 径 一 般 
为 “/var/lib/docker/init/dockerinit-1.2.0”。 另 外 SysProcAttr 使 用 
以 下 的 代码 来 赋值 


&syscall.SysProcAttr{ 
Cloneflags: uintptr(namespaces.GetNamespaceFlags (container.Namespaces)), 
} 


在 syscall.SysProAttr 对 象 中 的 Cloneflags 属 性 中 ， 即 保留 了 
libcontainerConfig 类 型 的 实例 Container 中 的 Namespaces 属 性 。 
换言之 ， 通 过 exec.Cmd 创 建 进程 时 ,libcontainer 正 是 通过 
Cloneflags 来 实现 在 Clone 系 统 调用 中 传 和 namespaces 参 数 标志 。 


回 到 消 数 执行 中 ， 在 陆 数 的 最 后 返回 了 c.Cmd , 命令 创建 完毕 。 


7.6.2 ”启动 exec.Cmd 创 建 进 程 


创建 完 exec.Cmd ,当然 需要 执行 该 命令 ，namespaces.Exec 


函数 中 直接 使 用 以 下 源码 实现 进程 的 局 动 : 


if err := command.Start(); err != nil { 
return -1, err 


这 一 部 分 的 内 容 简 单 直接 ，Start( ) 函数 用 以 完成 指定 命令 
exec.Cmd 的 启动 执行 ， 同 时 不 等 待 其 局 动 完 便 返 回 。Start( ) 消 数 
的 定义 位 于 os/exec 包 。 


进入 os/exec 包 ,查看 Start( ) 限 数 的 实现 ， 可 以 看 到 执行 过 程 
中 ,会 对 command.Process 进 行 赋值 ， 此 时 command.Process 中 
会 含有 刚才 局 动 进程 的 PID 进 程 号 ， 该 Pid 号 在 答 主 机 pid 
namespace 下 ,而 并 非 是 新 创建 的 namespace 下 的 Pid 号 。 


7.6.3 ”为 容器 进程 初始 化 网 络 环境 


上 一 环节 实现 了 容 颖 进程 的 启动 ,然而 还 没有 为 之 配置 相应 的 网 
络 环境 。namespaces.Exec 在 之 后 的 InitializeNetworing 中 实现 了 
为 容 希 进程 初始 化 网 络 环境 。 初 始 化 网 络 环境 需要 两 个 非常 重要 的 参 
数 : container 对 象 以 及 容 颖 进程 的 Pid 号 。 类 型 为 
libcontainer.Config 的 实例 container 包 含 用 户 对 Docker 容 器 的 网 
络 配置 需求 ， 另 外 容器 进程 的 Pid 可 以 使 得 创建 的 网 络 环境 与 进程 新 创 
建 的 Namespace 进 行 关联 。 


namespaces.Exec 中 为 容 希 进程 初始 化 网 络 环境 的 代码 实现 位 
于 . 川 bcontainernamespaces/exec.go#L75-L79 ,如 下 所 示 : 


if err := InitializeNetworking(container, command.Process.Pid, syncPipe, 
SnetworkState); err != nil 

command.Process .Kill() 

command .Wait() 

return -1, err 


} 


InitializeNetworing 的 作用 很 明显 ， 即 为 创建 的 容 莫 进程 初始 化 
网 络 环境 。 具 体 实现 包含 两 个 步 又 : 


1) 先 在 容 旨 进 程 的 网 络 命 名 空间 外 部 创建 该 容 右 所 需 的 网 络 
栈 。 


2) 将 创建 的 网 络 栈 传递 至 容 怖 的 网 络 命名 空间 。 


IntializeNetworking 的 源 代 码 实 现 位 
于 ./libcontainer/namespaces/exec.go#L176-L187 ,如 下 所 


小: 


func InitializeNetworking(container *libcontainer.Config, nspid int, pipe 
*syncpipe.SyncPipe, networkState *network.NetworkState) error 
for , config := range container.Networks { 


strategy, err := network.GetStrategy (config.Type) 
if err != nil { 
return err 
} 
if err := strategy.Create((*network.Network) (config), nspid, 
networkState); err != nil 
return err 
} 


return pipe.SendToChild(networkState) 
} 


以 上 源码 实现 过 程 ， 首 先 通过 一 个 循环 ， 允 历 
libcontainerConfig 类 型 实例 container 中 的 网 络 属 性 Networks ; 
随后 使 用 GetStrategy 函 数 处理 Networks 中 每 一 个 对 象 的 Type 属 
性 ， 得 出 Network 的 类 型 ， 这 里 的 类 型 有 3 种 ， 分 别 为 Joopback、 
veth 和 netns。loopback 环 回 接口 针对 bridge 模 式 和 none 模 式 ; 
veth 针 对 bridge 模 式 ; 而 netns 针 对 other container 模 式 。 


得 到 Network 的 类 型 之 后 , libcontainer 创 建 相 应 的 网 络 栈 ,有 具 
体 实 现 使 用 每 种 网 络 栈 类 型 下 的 Create 函 数 。 下 面 分 析 三 种 不 同 网络 
栈 各 自 的 创建 流程 。 需 要 额外 注意 的 是 : 容 需 网 络 村 的 创建 不 在 容 善 


网 络 命名 空间 之 内 ， 而 是 在 Docker Daemon 所 在 的 网 络 命名 空间 
内 。 


1.loopback 网 络 栈 的 创建 


loopback 是 一 种 本 地 环 回 接 口 ,libcontainer 创 建 loopback 网 
络 设备 的 实现 代码 位 于 ./libcontainer/network/loopback.go#L13- 
L15 , 如 下 所 示 : 


func (Ll *Loopback) Create(n *Network, nspid int, networkState *NetworkState) 
error { 
return nil 


令 人 费解 的 是 ,libcontainer 在 loopback 接 口 的 创建 毅 数 
Create 中 ， 并 没有 实质 性 的 内 容 ， 而 是 直接 返回 nil。 其 实 关 于 
loopback 接 口 的 创建 ， 要 回 到 Linux 内 核 为 进程 新 建 net 
namespace 的 阶段 。 当 libcontainer 执 行 Command.Start( ) 时 ， 
由 于 创建 了 一 个 新 的 net namespace，, 故 Linux 内 核 会 自动 为 新 的 
net namespace 创 建 一 个 loopback 接 口 。 当 Linux 内 核 创建 完 
loopback 接 口 之 后 , libcontainer 所 做 的 工作 即 只 保留 loopback 设 
备 的 默认 配置 ， 并 在 后 续 libcontainer 的 Initialize 函 数 中 实现 启动 该 
接口 。 


2.veth 网 络 栈 的 创建 


veth 是 Docker 容 器 实际 使 用 的 网 络 策略 之 一 ， 实 现 手段 是 : 使 
用 网 桥 docker0 并 创建 veth pair 虚 拟 网 络 接口 对， 最终 使 一 个 veth 
附加 在 宿主 机 的 docker0 网 桥 之 上 ，, 而 另 一 个 veth 安 置 在 容器 的 net 


namespace 内 部 。 


libcontainer 中 实现 veth 接 口 的 代码 非常 通俗 易 懂 ， 位 
于 ./dockerlibcontainernetwork/veth.go#L19-L50 , 如 下 所 


小: 

namel, name2, err := createVethPair(prefix) 

if err != nil { 
return err 

if err := SetInterfaceMaster(namel, bridge); err != nil { 
return err 

if err := SetMtu(namel, Nn.Mtu); err != nil { 
return err 

if err := InterfaceUp(namel); err != nil { 
return err 

} 

if err := SetInterfaceInNamespacePid(name2, nspid); err != nil { 
return err 

} 


主要 的 流程 包含 以 下 四 个 步骤 : 
1) 在 答 主 机 上 创建 veth pair。 
2) 将 一 个 veth 附 加 至 docker0 网 桥 上 。 


3) 启动 第 一 个 veth. 


) 将 第 二 个 veth 附 加 至 libcontainer 创 建 进程 的 namespace 
|( : 并 未 局 动 第 二 个 veth) 。 


使 用 Create 组 数 实 现 veth_ pair 的 创建 之 后 ,libcontainer 在 
Initialize 国 数 中 实现 将 网 络 namespace 中 的 veth 改 名 为 “eth0"”、 设 
置 网 络 设备 的 MTU、 以 及 局 动 网 络 接口 等 。 


3.netns 网 络 栈 的 创建 


netns 针 对 Docker 容 器 的 other container 网 络 模式 服务 。 
netns 完 成 的 工作 是 : 将 其 他 容器 的 net namespace 路 径 ， 传递 给 需 
要 创建 other container 网 络 模式 的 容器 使 用 .。 


libcontainer 中 实现 netns 策 略 的 源码 位 
于 ./docker/libcontainer/network/netns.go#L17-L20 , 如 下 所 


小 : 


func (v *NetNS) Create(n *Network, nspid int, networkState *NetworkState) error { 
networkState.NsPath = n.NsPath 
return nil 


} 


libcontainer 使 用 Create 哨 数 先 将 NsPath 传 递 给 新 建 容器 ,再 
在 Initialize 哆 数 中 实现 将 net namespace 的 文件 描述 符 交 由 新 创建 
容 肴 使用， 最 终 实现 两 个 Docker 容 背 共 享 同一 个 网 络 村 。 


通过 Create 兄 数 ，Docker 容 器 相应 的 网 络 栈 环境 即 已 经 完成 创 
建 ， 初 始 化 工作 有 待 Initialize 角 数 来 完成 。 详 见 本 书 第 13 章 ， 有 关 
dockerinit 的 执行 将 完成 容器 网 络 栈 的 初始 化 。 


7.7 总 结 


如 何 使 用 Docker 容 希 的 网 络 ， 一 直 是 工业 界 关 心 的 问题 。 本 章 从 
Linux 内 核 原 理 的 角度 阐述 了 什么 是 Docker 容 右 ， 并 对 Docker 容 器 
的 4 种 网 络 模式 进行 了 初步 的 介绍 ， 最终 员 窒 Docker 染 构 中 的 多 个 模 
块 ,如 Docker Client、Docker Daemon、execdriver 以 及 
libcontainer , 深入 分 析 了 Docker 容 器 网 络 的 实现 。 


目前 ， 若 只 谈论 Docker ,那么 它 还 是 只 停留 在 单 宿 主机 的 场景 
上 。 如 何 面 对 跨 宿主 机 的 场景 、 如 何 实现 分 布 式 Docker 容 需 的 管理 ， 
目前 为 止 还 没有 一 个 一 劳 永 逸 的 解决 方案 。 再 者 ， 一 个 解决 方案 的 存 
在 , 总 是 会 适应 于 一 个 应 用 场景 。Docker 这 种 容器 技术 的 发 展 ， 大 大 
改善 了 传统 模式 下 使 用 诸如 虚拟 机 等 传统 计算 单位 存在 的 多 种 浆 端 ， 
却 在 网 络 方面 使 得 自身 的 使 用 存在 璃 症 。 希 望 本章 是 一 个 引子 ， 介 绍 
Docker 容 器 网 络 ， 从 源码 的 角度 分 析 Docker 容 器 网 络 之 后 ， 能 使 更 
多 的 Docker 爱 好 者 思考 Docker 容 冀 网 络 的 来 龙 去 脉 ， 并 为 Docker 记 
至 容器 技术 的 发 展 做 出 贡献 。 


第 8 草 ”Docker 镜 像 


8.1 引言 


2014 年 ，Docker 便 在 全 球 乔 起 了 一 阵 又 一 阵 的 “ 容 硕 风 ” ,全球 
的 开发 者 开始 认识 Docker , 学 习 Docker。 又 过 了 一 年 ， 工 业界 对 
Docker 的 态度 已 经 不 再 是 了 解 与 观望 ， 转 而 是 实践 一 波 高 过 一 波 。 
Docke[ 自 前 的 发 展 似乎 并 不 会 像 其 他 县 花 一 现 的 技术 一 样 ， 反 而 是 赁 
借 创 新 性 的 特性 ,Docker 在 工业 界 经 过 实践 与 评估 之 后 , 显现 了 前 所 
未 有 的 潜力 。 


究 其 本 质 ,“Docker 提 供 容器 服务 "这 名 话 ， 相 信 很 少 有 人 会 有 异 
议 。 既然 如 此 ,Docker 提 供 的 服务 属于 “ 容 右 "技术 ,那么 反观 “ 容 
妖 " 技 术 的 本 质 与 发 展 历史 ,我们 又 可 以 发 现 什 么 呢 ? 正如 第 7 章 所 提 
到 的 ，Docker 使 用 的 “容器 "技术 ， 主 要 是 以 Linux 内 核 的 
namespace、cgroup 等 特性 为 基础 ， 保 障 进程 或 者 进程 组 处 于 一 个 
隔离 、 受 限 、 安 全 的 环境 之 中 。Docker 第 一 个 版 本 在 2013 年 3 月 发 
行 ， 而 cgroups 正 式 在 Linux 操 作 系统 中 的 亮相 可 以 追溯 到 2007 年 下 
半年 ,当时 cgroups 被 合并 至 Linux 内 核 2.6.24 版 本 。 这 整整 6 年 时 间 
并 不 是 Linux 平 台 “ 容 右 " 技 术 发 展 的 真空 期 。2008 年 LXC( Linux 
Containen 诞生 , 它 简 化 了 容 展 的 创建 与 管理 ; 之 后 业界 一 些 Paas 


平台 也 初步 党 试 采用 容 郑 技 术 作为 其 云 应 用 的 运行 环境 。 而 在 Docker 
发 布 的 同年 ,Google 也 发 布 了 开源 容 闫 管理 工具 Imctfy。 除 此 之 

外 ， 知 抛 开 Linux 操 作 系统 ， 其 他 操作 系统 ( 如 FreeBSD、Solaris 
等 ) 同样 诞生 了 作用 类 似 的 “ 容 希 "技术 ， 其 发 展 历史 更 是 可 以 追溯 至 
干 禧 年 初期 。 


总 之 ,“ 容 问 " 技 术 的 发 展 不 可 谓 短暂 ， 然 而 论 同 时 代 的 影响 力 ， 
却 鲜 有 Docker 的 媲美 者 。 不 论 是 云 计 算 大 潮 催生 了 Docker 技 术 ， 抑 
或 是 Docker 技 术 赶 上 了 云 计算 的 大 时 代 ， 毋 庸 症 疑 的 是 ，Docker 作 
为 技术 领域 的 新 宠儿 ， 必 将 继续 受到 业界 的 广泛 青睐 。 云 计算 时 代 ， 
分 布 式 应 用 逐渐 流行 ， 大 部 分 应 用 对 自身 的 构建 、 交 付 与 运行 都 有 着 
与 传统 不 一 样 的 需求 。 借 助 Linux 内 核 的 namespace 和 cgroup 等 特 
性 ,自然 可 以 实现 应 用 运行 环境 的 资源 隔离 与 限制 等 ; 然而 ， 
namespace 和 cgroup 等 内 核 特性 却 无 法 为 容 痪 的 运行 环境 做 全 盘 打 
包 。 而 Docker 的 设计 则 非常 巧妙 地 考虑 到 了 这 一 点 , 除 namespace 
和 cgroup 之 外 ,Docker 另 外 采用 了 神奇 的 “镜像 "技术 作为 Docker 管 
理 文件 系统 以 及 运行 环境 强 有 力 的 补充 。Docker 灵 活 的 “镜像 " 技 
术 ， 在 笔者 看 来 ， 也 是 其 大 红 大 紫 最 重要 的 因素 之 一 。 


8.2 ” ”Docker 镜像 介绍 


Docker 诞 生 至 今 ， 很 多 容器 领域 从 业者 都 会 将 Docker 技 术 与 虚 

拟 机 技术 相提并论 。 提 及 Docker 镜 像 ， 大 家 肯定 也 会 联想 到 虚拟 机 中 
的 镜像 。 镜 像 是 一 种 文件 存储 形式 ， 文 件 管理 员 可 以 通过 技术 手段 将 

很 多 文件 制作 成 一 个 镜像 。 对 于 虚拟 机 而 言 ， 镜像 文件 中 存储 着 操作 

系统 、 文 件 系统 内 容 、 设 备 文件 等 。 可 以 说 ，Docker 镜 像 与 虚拟 机 镜 
像 有 很 大 的 相似 度 ， 然 而 也 有 着 本 质 的 区 别 。 相 似 的 是 ， 两 者 存储 内 

容 大 致 相同 ， 都 会 含有 文件 系统 内 容 ; 不 同 的 是 ，Docker 镜 像 不 含 操 
作 系 统 内 容 ， 同时 Docker 镜 像 由 多 个 镜像 组 成 。 


根据 Docker 官 方 网 站 上 的 技术 文档 描述 ，image( 镜像 ) 是 
Docker 术 语 的 一 种 ， 对 于 容 妖 而 言 ， 它 代表 一 个 只 读 的 layer。 而 
layer 则 具体 代表 Docker 容 妖 文 件 系 统 中 可 受 加 的 一 部 分 。 


如 此 介绍 Docker 镜 像 ， 相 信众 多 Docker 爱 好 者 理解 起 来 仍然 是 
云 里 雳 里 。 那 么 理解 之 前 ， 先 让 我 们 来 认识 一 下 与 Docker 镜 像 相 关 的 


4 个 概念 : rootfs、union mount、image 以 及 layer。 


8.3 rootfs 


rootfs 代 表 一 个 Docker 容 器 在 启动 时 ( 而 非 运行 后 ) 其 内 部 进程 
可 见 的 文件 系统 视角 ， 或 者 Docker 容 器 的 根 目录 。 当 然 ,该 目录 下 含 
有 Docker 容 器 所 需要 的 系统 文件 、 工 具 、 容 器 文件 等 。 


传统 上 ,Linux 操 作 系统 内 核 启动 时 ,内核 首 先 会 挂 载 一 个 只 读 
( read-only) 的 rootfs , 当 系 统 检测 其 完整 性 之 后 ,决定 是 否 将 其 
切换 为 读 写 ( read-write) 模式 ， 或 者 最 后 在 rootfs 之 上 另行 挂 载 一 
种 文件 系统 并 包 略 rootfs。Docker 架 构 下 ， 依 然 沿 用 Linux 中 rootfs 
的 思想 。 当 Docker Daemon 为 Docker 容 妖 挂 载 rootfs 的 时 候 ， 与 传 
统 Linux 内 核 类 似 ， 将 其 设 定 为 只 读 模式 。 在 rootfs 挂 载 完 毕 之 后 ， 
和 Linux 内 核 不 一 样 的 是 ，Docker Daemon 没 有 将 Docker 容 器 的 文 
件 系统 设 为 读 写 模式 ， 而 是 利用 Union Mount 的 技术 ， 在 这 个 只 读 的 
rootfs 之 上 再 挂 载 一 个 读 写 的 文件 系统 ， 挂 载 时 该 读 写 文 件 系统 内 空 
无 一 物 。 在 这 里 ， 我 们 暂且 把 Docker 容 闫 的 文件 系统 这 人 么 理解 : 只 含 
只 读 的 rootfs 和 可 读 与 的 文件 系统 。 


举 一 个 Ubuntu 容 闫 局 动 的 例子 。 假 设 用 户 已 经 通过 Docker 
Registry 下 拉 了 Ubuntu : 14.04 的 镜像 ， 并 通过 命令 docker run-it 
ubuntu : 14.04/bin/bash 将 其 启动 并 运行 ， 则 Docker Daemon 为 
其 创建 的 rootfs 以 及 容 问 可 读 写 的 文件 系统 如 图 8-1 所 示 。 


/bin /dev /home /lib64 /mnt /proc 


/srvy /tmp /var /boot /lib /ete ( 只 污 文 件 系 统 ) 


/media /opt /root /sbin /sys /usr ( rootfs ) 





图 8-1 Ubuntu 14.04 容 器 文件 系统 示意 图 


顾名思义 ， 该 容器 中 的 进程 对 rootfs 中 的 内 容 只 拥有 读 权限 ， 对 
于 读 写 文件 系统 中 的 内 容 既 拥有 读 权限 也 拥有 写 权限 。 通 过 观察 图 8- 
1 可 以 发 现 : 容器 虽然 只 有 一 个 文件 系统 ， 但 该 文件 系统 由 “两 层 " 组 
成 ， 分 别 为 读 与 文件 系统 和 只 读 文件 系统 。 通 过 这 样 的 理解 ， 文 件 系 
统 已 然 有 了 层级 ( layen 的 意味 。 


简单 来 讲 ， 可 以 将 Docker 容 器 的 文件 系统 分 为 两 部 分 ， 而 前 面 提 
到 的 Docker Daemon 利 用 Union Mount 技 术 , 将 两 者 挂 载 。 那 么 
Union Mount 又 是 一 种 怎样 的 技术 ? 下 一 节 将 介绍 Union Mount 的 
概念 。 


8.4 Union Mount 


Union Mount 代 表 一 种 文件 系统 挂 载 方式 ， 人 允许 同一 时 刻 多 种 文 
件 系 统合 加 挂 载 在 一 起 ， 并 以 一 种 文件 系统 的 形式 ， 呈 现 多 种 文件 系 
统 内 容 合 并 后 的 目录 。 


一 般 情况 下 ， 若 通过 某 种 文件 系统 挂 载 内 容 至 挂 载 点 ， 挂 载 点 目 

录 中 原先 的 内 容 将 会 被 隐藏 。 而 Union Mount 则 不 会 将 挂 载 点 目录 中 
的 内 容 隐藏 ， 反 而 是 将 挂 载 点 目录 中 的 内 容 和 被 挂 载 的 内 容 合 并 ， 并 
为 合并 后 的 内 容 提供 一 个 统一 独立 的 文件 系统 视角 。 通 常 来 讲 ， 被 合 
并 的 文件 系统 中 只 有 一 个 会 以 读 写 ( read-write) 模式 挂 载 ， 其 他 文 
件 系统 的 挂 载 模式 均 为 只 读 ( read-only) 。 实 现 这 种 Union Mount 
技术 的 文件 系统 一 般 称 为 联合 文件 系统 ( Union Filesystem) ， 较 为 
常见 的 有 UnionFS、aufs、OverlayFS 等 。 


Docker 实 现 容 背 文件 系统 Union Mount 时 ， 提 供 多 种 具体 的 文件 
系统 解决 方案 ， 如 Docker 早 期 版 本 沿用 至 今 的 AUFS， 还 有 在 Docker 
1.4.0 版 本 中 开始 支持 的 OverlayFS 等 。 


为 了 更 深入 地 了 解 Union Mount , 可 以 使 用 aufs 文 件 系统 来 进 一 
步 阐述 本 章 前 面 Ubuntu : 14.04 容 器 文件 系统 的 例子 ， 挂 载 Ubuntu 
14.04 文 件 系统 的 示意 图 如 图 8-2 所 示 。 


使 用 镜像 Ubuntu : 14.04 创 建 的 容 希 中 ， 可 以 暂且 将 该 容 闫 的 整 
个 rootfs 当 成 一 个 文件 系统 。 前 面 也 提 到 ， 挂 载 时 读 写 文件 系统 中 空 无 
一 物 。 既 然 如 此 ， 从 用 户 视 角 来 看 ， 容 需 内 文件 系统 和 rootfs 完 全 一 
样 ， 用 户 完全 可 以 按照 往常 习惯 ， 无 差别 地 使 用 自身 视角 下 文件 系统 
中 的 所 有 内 容 ; 然而 ， 从 内 核 的 角度 来 看 ， 两 者 有 非常 大 的 区 别 。 追 
济 区 别 存 在 的 根本 原因 ， 那 就 不 得 不 提 及 aufs 等 文件 系统 的 COW 
( copy-on-write) 特性 。 


读 写 文件 系统 





home lib64 mnt 
var boot ib 


sbin 


home /1ib64 





( 读 写 文件 系统 ) 
内 核 视角 /bin /dev /home /1ib64 /mnt 

/srV tmp /var /boot /ib Re De 
(只 读 文件 系统 ) 


(rootfs) 


图 8-2 aufs 挂 载 Ubuntu 14.04 文 件 系统 的 示意 图 


/media /opt root /sbin /sys /usr 





COW 文 件 系 统 和 其 他 文件 系统 最 大 的 区 别 就 是 : 前 者 从 不 覆 与 已 
有 文件 系统 中 已 有 的 内 容 。 通 过 COW 文 件 系统 将 两 个 文件 系统 
( rootfs 和 读 与 文件 系统 ) 合并 ， 最终 用 户 视角 为 合并 后 含有 所 有 内 容 


的 文件 系统 ， 然 而 在 Linux 内 核 逻辑 上 依然 可 以 区 别 两 者 ， 那 就 是 用 户 
对 原先 rootfs 中 的 内 容 拥 有 只 读 权 限 ， 而 对 读 与 文件 系统 中 的 内 容 拥有 
读 瑟 权限 。 


既然 对 用 户 而 言 ,全然 不 知 哪些 内 容 只 读 , 哪些 内 容 可 读 写 ， 这 
些 信息 只 有 内 核 在 接管 ， 那 么 假设 用 户 需要 更 新 其 视角 下 的 文 
件 /etc/bash.bashrc , 而 该 文件 又 恰巧 是 rootfs 只 读 文件 系统 中 的 内 
容 ， 内 核 是 否 会 抛 出 异常 或 者 驳回 用 户 请 求 呢 ? 答案 是 否定 的 。 当 此 
情形 发 生 时 ，COW 文 件 系统 首先 不 会 覆 写 只 读 文件 系统 中 的 文件 ， 即 
不 会 覆 写 rootfs 中 的 /etc/bash.bashrc , 其 次 反而 会 将 该 文件 复制 至 
读 写 文件 系统 中 ， 即 将 /etc/bash.bashrc 复 制 至 读 写 文件 系统 中 
的 /etc/bash.bashrc( 此 时 ，rootfs 文 件 系统 和 读 写 文件 系统 中 各 含 
有 一 份 /etc/bash.bashrc) ， 最 后 再 对 后 者 进行 更 新 操作 。 如 此 一 
来 ， 纵 使 rootfs 与 读 写 文件 系统 中 均 有 /etc/bash.bashrc ,诸如 aufs 
类 型 的 COW 文 件 系统 也 能 保证 用 户 视角 中 只 能 看 到 读 写 文件 系统 中 
的 /etc/bash.bashrc , 即 更 新 后 的 内 容 。 


当然 ， 这 样 的 特性 同样 支持 rootfs 中 文件 的 删除 等 其 他 操作 。 例 
如 : 用 户 通 过 apt-get 软 件 包 管理 工具 安装 Golang， 所 有 与 Golang 相 
关 的 内 容 都 会 安装 在 读 写 文件 系统 中 ， 而 不 会 安装 在 rootfs 中 。 此 时 用 
户 又 希望 通过 apt-get 软 件 包 管理 工具 删除 所 有 关于 MySQL 的 内 容 ， 
恰巧 这 部 分 内 容 又 都 存在 于 rootfs 中 ， 人 删除 操作 执行 时 同样 不 会 删除 


rootfs 实 际 存在 的 MySQL , 而 是 在 读 写 文件 系统 中 删除 该 部 分 内 容 ， 

导致 最 终 rootfs 中 的 MySQL 对 容器 用 户 不 可 见 ， 也 不 可 访 。 由 于 读 写 
文件 系统 中 根本 不 存在 MySQL 的 相关 内 容 ， 因 此 似乎 在 读 写 文件 系统 
中 找 不 到 需要 删除 的 对 象 。 此 时 ，aufs 保 障 在 读 写 文件 系统 中 对 这 些 
文件 内 容 做 相关 的 标记 ( whiteout ， 确保 用 户 在 查看 文件 系统 内 容 
时 ， 读 写 文 件 系统 中 的 whiteout 将 遮盖 住 rootfs 中 的 相应 内 容 ， 导 致 
这 些 内 容 不 可 见 ， 以 达到 与 删除 这 部 分 内 容 相 类 似 的 效果 。 


掌握 Docker 中 rootfs 以 及 Union Mount 的 概念 之 后 ， 再 来 理解 
Docker 镜 像 ， 就 会 有 水 到 渠 成 的 感觉 。 


8.5 Image 


Docker 中 rootfs 的 概念 ， 起 到 容 闫 文件 系统 中 基石 的 作用 。 对 于 
容器 而 言 ,其 只 读 的 特性 也 是 不 难 理解 。 神 奇 的 是 ， 实 际 情况 下 
Docker 架 构 中 rootfs 的 设计 与 实现 比 前 面 的 描述 还 要 精妙 得 多 。 


继续 以 Ubuntu 14.04 为 例 , 虽然 通过 aufs 可 以 实现 rootfs 与 读 与 
文件 系统 的 合并 ， 但 是 考虑 到 rootfs 自 身 接近 200MB 的 磁盘 大 小 ， 如 
果 以 这 个 rootfs 的 粒度 来 实现 容 需 的 创建 与 迁移 等 ， 是 人 否 会 稍 显 条 重 ? 
同时 也 会 大 大 降低 镜像 的 灵活 性 ? 而且， 若 用 户 希 望 拥 有 一 个 Ubuntu 
14.10 的 rootfs， 那么 是 否 有 必要 创建 一 个 全 新 的 rootfs ， 毕 竟 
Ubuntu 14.10 和 Ubuntu 14.04 的 rootfs 中 有 很 多 一 致 的 内 容 。 


Docker 中 image 的 概念 ， 非 常 巧妙 地 解决 了 以 上 问题 。 最 为 简单 
地 解释 Image，, 它 就 是 Docker 容 希 中 只 读 文 件 系统 rootfs 的 一 部 分 。 
换言之 ， 实际 上 Docker 容 希 的 rootfs 可 以 由 多 个 image 来 构成 。 多 个 
image 构 成 rootfs 的 方式 依然 沿用 Union Mount 技术 。 


多 个 image 构 成 的 rootfs 如 图 8-3 所 示 ( 其 中 ,rootfs 中 每 一 层 
image 中 的 内 容 划 分 只 为 了 阐述 清楚 rootfs 由 多 个 image 构 成 ， 并 不 
代表 实际 情况 下 rootfs 中 的 内 容 划 分 ) 


读 写 文件 系统 





imagelD 3 
| /media /opt /home imagelD 2 
rootfs , 
《zw 八 上 3r. (fF A 
(多 个 镜像 ) /bin /dev /usr /lib64 、 imagelD 1 
imagelD 0 





图 8-3 ”容器 rootfs 多 image 构 成 图 


从 图 8-3 中 我 们 可 以 看 出 ， 容 器 rootfs 包 含 4 个 image , 其 中 每 个 
image 中 都 有 一 些 用 户 视角 文件 系统 中 的 一 部 分 内 容 。4 个 image 处 于 
层 释 的 关系 , 除了 最 底层 的 image , 每 一 层 的 image 都 琶 加 在 另 一 个 
image 之 上 。 另 外 ,每 一 个 image 均 含有 一 个 image ID ， 用 于 唯一 地 


标记 该 image。 


基于 以 上 概念 ，Docker Image 中 又 抽象 出 两 种 概念 : 父 镜像 以 
及 基础 镜像 。 除 了 容 硕 rootfs 最 欣 层 的 镜像 ， 其 余 镜 像 都 依赖 于 其 欣 下 
的 一 个 或 多 个 镜像 。 这 种 情况 下 ，Docker 将 下 一 层 的 镜像 称 为 上 一 层 
镜像 的 父 镜 像 。 以 图 9-3 为 例 , imagelD_0 是 imagelD_1 的 父 镜像 ， 
imagelD 2 是 imagelD 3 的 父 镜 像 ， 而 imagelD 0 没有 父 镜像 。 对 
于 最 下 层 的 镜像 ， 即 没有 父 镜像 的 镜像 ， 在 Docker 中 我 们 习惯 称 之 为 
基础 镜像 。 


通过 image 的 形式 ， 原 先 较为 肽 肿 的 rootfs 被 逐渐 打 散 成 轻便 的 
多 层 。 除 了 轻便 的 特性 之 外 ,image 同时 还 有 前 面 提 到 的 只 读 特 性 ， 


如 此 一 来 ， 在 不 同 的 容器 、 不 同 的 rootfs 中 image 完 全 可 以 用 来 复 
用 。 


多 image 组 织 关 系 与 复 用 关系 如 图 8-4 所 示 ( 图 中 镜像 名 称 的 举例 
只 为 将 image 之 间 的 关系 阐述 清楚 ， 并 不 代表 实际 情况 下 相应 名 称 
image 之 间 的 关系 ) 


imagelD 3 





imageID 5 


图 8-4 ”多 image 组 织 关系 示意 图 


图 8-4 中 ， 共 罗列 了 11 个 image , 这 11 个 image 之 间 的 关系 呈现 
为 一 幅 森 林 图 。 和 森林 中 售 有 两 棵 树 ,左边 树 中 包含 5 个 节点 ， 即 含有 5 
个 image ; 右边 树 中 包含 6 个 节点 ， 即 含有 6 个 image。 其 中 ， 有 些 
image 标 记 了 加 粗 的 字段 ， 这 童 味 该 image 代 表 某 一 种 容器 镜像 
rootfs 的 最 上 层 image。 如 ubuntu : 14.04 ,代表 imagelD 3 为 该 类 
型 容 颖 rootfs 的 最 上 层 ，, 沿 着 该 节点 找到 树 的 根 节点 ， 可 以 发 现 路 径 上 


还 有 imagelD_2、imagelD_1 和 imagelD_0。 特 殊 的 是 ， 
imagelD_2 作 为 imagelD_3 的 父 镜像 ， 同 时 又 是 容器 镜像 ubuntu : 
12.04 的 rootfs 中 的 最 上 层 ， 可 见 镜像 ubuntu : 14.04 只 是 在 镜像 
ubuntu : 12.04 之 上 再 另行 和 加 了 一 层 。 因 此 ， 在 下 载 镜像 
Ubuntu : 12.04 以 及 ubuntu : 14.04 时 ， 只 会 下 载 一 份 
imagelD 2、imagelD 1 和 imagelD_ 0 , 实现 image 的 复 用 。 同 
时 ,右边 树 中 mysql : 5.6、mongo : 2.2、debian : wheezy 和 
debian : jessie 也 呈现 同样 的 关系 。 


8.6 layer 


在 Docker 中 ， 术语 layer 是 一 个 与 image 含 义 较为 相近 的 词 。 容 
器 镜像 的 rootfs 是 容器 只 读 的 文件 系统 ，rootfs 又 由 多 个 只 读 的 
image 构 成 。 于 是 ，rootfs 中 每 个 只 读 的 image 都 可 以 称 为 一 个 


layer, 


除了 只 读 的 image 之 外 , Docker Daemon 在 创建 容 颖 时 会 在 容 
妖 的 rootfs 之 上 , 再 挂 载 一 层 读 写 文件 系统 ， 而 这 一 层 文 件 系 统 也 称 
为 容 莫 的 一 个 layer , 党 被 称 为 top layer。 实 际 情况 下 ，Docker 还 会 
在 rootfs 和 top layer 之 间 再 挂 载 一 个 layer , 这 一 个 layer 中 主要 包含 
的 内 容 是 /etc/hosts、/etc/hostname 以 及 /etc/resolv.conf , 一 般 
这 一 个 layer 称 为 init layer。 为 了 简化 阐述 流程 ， 我 们 暂 不 提 init 


layer, 


因此 , 总之， Docker 容 背 中 每 一 层 只 读 的 image 以 及 最 上 层 可 
读 写 的 文件 系统 ， 均 称 为 layer。 如 此 一 来 ，layer 的 范畴 比 image 多 
了 一 层 , 即 多 包含 了 最 上 层 的 读 写 文件 系统 。 


有 了 layer 的 概念 ， 大 家 可 以 思考 这 样 一 个 问题 : 容器 文件 系统 分 
为 只 读 的 rootfs， 以 及 可 读 写 的 top layer ,那么 容 闫 运行 时 若 在 top 


layer 中 写 入 了 内 容 , 这 些 内 容 是 否 可 以 持久 化 ， 并且 也 被 其 他 容器 复 
用 ? 


本 章 对 于 image 的 分 析 中 ， 提 到 了 image 有 复 用 的 特性 ,既然 如 
此 ,再 提出 一 个 更 为 大 胆 的 假设 : 容器 的 top layer 是 否 可 以 转变 为 


image? 


答案 是 肯定 的 。Docker 的 设计 理念 中 ，top layer 转 变 为 image 
的 行为 ( Docker 中 称 为 commit 操 作 ) 进一步 释放 了 容 颖 rootfs 的 灵 
活性 。Docker 的 开发 者 完全 可 以 基于 某 个 镜像 创建 容 医 做 开发 工作 ， 
并 且 无 论 在 开发 周期 的 哪个 时 间 点 ， 都 可 以 对 容 痪 进行 commit , 将 
所 有 top layer 中 的 内 容 打包 为 一 个 Image， 构 成 一 个 新 的 镜像 。 
commit 完 毕 之 后 ， 用户 完全 可 以 基于 新 的 镜像 ， 进行 开发 、 分 发 、 
测试 、 部 署 等 。 不 仅 Docker commit 的 原理 如 此 ， 基 于 Dockerfile 
的 docker build 最 为 核心 的 思想 ， 也 是 不 断 将 容 闫 的 top layer 转 化 
为 image。 


8.7 总结 


Docker 风 暴 席卷 全 球 并 非 偶 然 。 如 今 的 云 计算 时 代 下 ， 轻 量 级 容 
屁 技 术 与 灵活 的 镜像 技术 相 结合 ， 似 乎 颠覆 了 以 往 的 软件 交付 模式 ， 
为 持续 集成 ( Continuous Integration ,Cl) 与 持续 交付 


( Continuous Delivery ，CD) 的 发 展 带 来 了 全 新 的 契机 。 


理解 Docker 的 “镜像 "技术 ， 有 助 于 Docker 爱 好 者 更 好 地 使 用 、 
创建 以 及 交付 Docker 镜 像 。 基 于 此 ， 本章 从 Docker 镜 像 的 4 个 重要 
概 仿 入手， 介绍 了 Docker 镜 像 中 包含 的 内 容 ， 涉及 的 技术 ， 以 及 重要 
的 特性 。Docker 引 入 优秀 的 “镜像 "技术 时 ， 着 实 使 容器 的 使 用 变 得 
更 为 便利 ， 也 拓 让 了 Docker 的 使 用 范畴 。 然 而 ,与 此 同时 ， 我 们 也 应 
该 理性 地 看 待 镜像 技术 引入 时 ， 是否 会 带 来 其 他 副作用 ， 如 镜像 技术 
是 否 会 带 来 性 能 问题 等 都 将 是 我 们 进一步 思考 的 话题 。 


第 9 章 ”Docker 镜 像 下 载 
9.1 引言 


说 Docker Image 是 Docker 体 系 的 价值 所 在 ， 没 有 丝毫 的 夸张 。 
Docker Image 作 为 容 硕 运行 环境 的 基石 ， 彻 底 解放 了 Docker 容 需 的 
生命 力 ， 也 激发 了 用 户 对 于 容器 运用 的 无 限 相 象 力 。 


玩 转 Docker , 必然 离 不 开 Docker Image 的 支持 。 然 而 “万 物 区 
有 源 ”, Docker Image 来 自 何方 ，Docker Image 又 是 通过 何 种 途径 
传输 到 用 户 的 宿主 机 ， 以 致 用 户 可 以 通过 Docker Image 创 建 容 磺 的 
呢 ?回忆 初次 接触 Docker 的 场景 ， 大 家 肯定 对 两 条 命令 不 阳 生 : 
docker pull 和 docker run。 这 两 条 命令 中 ， 正 是 前 者 实现 了 Docker 
Image 的 下 载 。Docker Daemon 在 执行 这 条 命令 时 ， 会 将 Docker 
Image 从 Docker Registry 下 载 至 本 地 ， 并 保存 在 本 地 Docker 
Daemon 管 理 的 Graph 中 。 


谈 及 Docker Registry，Docker 爱 好 者 首先 联想 到 的 自然 是 
Docker Hub。Docker Hub 作 为 Docker 官 方 支持 的 Docker 
Registry， 拥有 全 球 成 二 上 万 的 Docker Image。 全 球 的 Docker 爱 
好 者 除了 可 以 下 载 Docker Hub 开 放 的 镜像 资源 之 外 ， 还 可 以 向 


Docker Hub 贡 献 镜 像 资 源 。 在 Docker Hub 上 ， 用 户 不 仅 可 以 享受 
公有 镜像 带 来 的 便利 ， 而 且 可 以 创建 私有 镜像 库 。Docker Hub 是 全 
国 最 大 的 Public Registry， 另 外 Docker 还 支持 用 户 自 定义 创建 
Private Registry。Private Registry 主 要 的 功能 是 为 私有 网 络 提供 
Docker 镜 像 的 专属 服务 ， 一 般 而 言 ， 镜 像 种 类 适应 用 户 需求 ， 私 密 性 
较 高 ， 且 不 会 占用 公有 网 络 带 友 。 


本 章 主 要 从 Docker 1.2.0 源 码 的 角度 分 析 Docker 下 载 Docker 
Image 的 过 程 。 分 析 内 容 主要 包括 以 下 4 部 分 : 


1) 概述 Docker 镜 像 下 载 的 流程 ， 涉 及 Docker Client、Docker 


Server 以 及 Docker Daemon :; 
2) Docker Client 处 理 并 发 送 docker pull 请 求 ; 


3) Docker Server 接 收 docker pull 请 求 ， 创建 镜像 下 载 任务 并 
触发 执行 ; 


4) Docker Daemon 执 行 镜像 下 载 任 务 ， 并 存储 镜像 至 
Graph。 


9.2 ” Docker 镜 像 下 载 流 程 


Docker Image 作 为 Docker 生 态 中 的 精髓 ， 下 载 过 程 中 需要 
Docker 架 构 中 多 个 组 件 的 协作 ,下载 流程 如 图 9-1 所 示 。 







Docker Client 


Docker Server 


Docker Registry 


| Job (pull) 
1mage 


Docker Daemon 
图 9-1 Docker 镜 像 下 载 流程 图 


如 图 9-1 所 示 ，Docker lImage 的 下 载 流程 可 以 归纳 为 以 下 3 个 步 


1) 用 户 通过 Docker Client 发 送 pull 请 求 ， 用 于 让 Docker 
Daemon 下 载 指定 名 称 的 镜像 ; 


2) Docker Server 接 收 Docker 镜 像 的 pull 请 求 ， 创建 下 载 镜像 
任务 并 触发 执行 ; 


3) Docker Daemon 执 行 镜像 下 载 任务 ， 从 Docker Registry 
中 下 载 指定 镜像 ， 并 将 其 存储 于 本 地 的 Graph 中 。 


9.3 Docker Client 


Docker 架 构 中 ，Docker 用 户 的 角色 绝 大 多 数 由 Docker Client 
来 扮演 。 因 此 ， 用户 对 Docker 的 管理 请 求全 部 由 Docker Client 来 发 
送 ，Docker 镜 像 下 载 请 求 自然 也 不 例外 。 


为 了 更 清晰 地 描述 Docker 镜 像 下 载 ， 本 节 结 合 具 体 的 命令 进行 分 
析 ,命令 如 下 : 


docker pull ubuntu:14.04 


此 命令 的 含义 是 : 通过 docker 二 进 制 可 执行 文件 ， 执行 镜像 下 载 
的 pull 命 令 ， 镜像 参 数 为 ubuntu : 14.04 ,镜像 名 称 为 ubuntu , 镜 
像 标签 ( tag) 为 14.04。 此 命令 一 经 发 起 ， 第 一 个 接受 并 处 理 的 
Docker 组 件 为 Docker Client ,执行 内 容 包括 以 下 三 个 步骤 : 


1) 解析 命令 中 与 Docker 镜 像 相关 的 参数 ; 
2) 配置 Docker 下 载 镜 像 时 所 需 的 认证 信息 ; 


3) 发 送 RESTful 请 求 至 Docker Daemon。 


9.3.1 解析 镜像 参数 


通过 docker 二 进 制 文件 执行 docker pull ubuntu : 14.04 时 ， 
Docker Client 首 先 会 创建 ， 随后 通过 参数 处 理 分 析出 请 求 类 型 
pull， 最 终 执 行 pull 请 求 相 应 的 处 理 郧 数 。 关 于 Docker Client 的 创建 


与 命令 执行 可 以 参见 第 2 章 。 


Docker Client 执 行 pull 请 求 相应 的 处 理 浮 数 ， 源 码 位 
于 ./docker/api/client/command.go#L1183-L1244 ,有 关 提 取 镜 
像 参 数 的 源码 如 下 : 


func (cli *DockerCli) CmdPull(args ...string) error { 
cmd := cli.Subcmd("pull", "NAME[:TAG]", "Pull an image or a repository 
from the registry") 
tag := cmd.String([]string{"#t", "#-tag"}, "", "Download tagged image 
in a repository") 
if err := cmd.Parse(args); err != nil { 
return nil 


} 

if cmd.NArg() != 1 { 
cmd .Usage() 
return nil 


var ( 
V 
remote 


= Url.Values{} 

= cmd.Arg(0) 

) 

v.Set("fromImage", remote) 

if *tag == "" { 
v.Set("tag", *tag) 


remote, = parsers,ParseRepositoryTag (remote) 
// Resolve the Repository name from fqn to hostname + name 
hostname, , err := registry.ResolveRepositoryName ( remote ) 
if err != nil { 

return err 
} 


结合 命令 docker pull ubuntu : 14.04 来 分 析 CmdPulI 印 数 的 定 
义 ,我 们 可 以 发 现 ， 该 函数 传 入 的 形 参 为 args， 实 参 是 字符 串 
ubuntu : 14.04。 另 外 ， 纵 观 以 上 源码 ， 可 以 发 现 Docker Client 解 
析 的 镜像 参数 无 外 乎 4 个 : tag、remote、v 以 及 hostname , 四 者 各 
自 的 作用 如 下 。 


tag : 带 有 Docker 镜 像 的 标签 ( 已 弃 用 ) 
-remote : 市 有 Docker 镜 像 的 名 称 与 标签 ; 


V : 类 型 为 url.Values , 实质 是 一 个 map 类 型 ， 用 于 配置 请 求 中 


URL 的 查询 参数 ; 


:hostname : Docker Registry 的 地 址 ， 代表 用 户 希 望 从 指定 的 
Docker Registry 下 载 Docker 镜 像 。 


1 .解析 tag 参 数 


Docker 镜 像 的 tag 参 数 ， 是 第 一 个 被 Docker Client 解 析 的 镜像 
参数 ， 代 表 用 户 所 需 下 载 Docker 镜 像 的 标签 信息 ， 如 docker pull 
ubuntu : 14.04 请 求 中 镜像 的 tag 信 息 为 14.04， 若 用 户 使 用 docker 
pull ubuntu 请 求 下 载 镜像 ， 没 有 显 式 指定 tag 信 息 时 ，Docker 
Client 会 黑 认 该 镜像 的 tag 信 息 为 atest。 


Docker 1.2.0 版 本 除了 以 上 的 tag 信 息 传 入 方式 之 外 ,依旧 保留 
着 代表 镜像 标签 的 flag 参 数 tag， 而 这 个 flag 参 数 在 1.2.0 版 本 的 使 用 
过 程 中 已 经 弃 用 ， 并 会 在 之 后 新 版 本 的 Docker 中 被 移 除 ， 因 此 在 使 用 
Docker 1.2.0 版 本 下 载 Docker 镜 像 时 ， 不 建议 使 用 flag 参 数 tag。 传 
入 tag 信 息 的 方式 ， 建 议 使 用 docker pull NAME[ : TAG] 的 形式 。 


关于 Docker 1.2.0 版 本 依旧 保留 的 flag 参 数 tag， 其 定义 与 解析 
的 源码 位 于 : ./docker/api/client/commands.go#1185-L1188， 
如 下 : 


tag := cmd.String([]string{"#t", "#-tag"}, "", "Download tagged image in a 
repository") 
if err := cmd. .Parse(args) ; err != nil { 

return ni 


以 上 源码 说 明 : CmdPul| 尔 数 解 析 tag 参 数 时 ,Docker Client 首 
先 定义 一 个 flag 参 数 ，flag 参 数 的 名 称 为 “#t" 或 者 “#-tag”, 用 途 
为 : 指定 Docker 镜 像 的 tag 参 数 ， 上 默认 值 为 空 字符 串 ; 随后 通过 
cmd.Parse( args) 的 执行 ,解析 args 中 的 tag 参 数 。 


2 .解析 remote 参 数 


Docker Client 解 析 完 tag 参 数 之 后 ， 同 样 需要 解析 出 Docker 镜 
像 所 属 的 repository ， 如 请 求 docker pull ubuntu : 14.04 中 ， 


Docker 镜 像 为 ubuntu : 14.04， 镜像 的 repository 信 息 为 
ubuntu , 镜像 的 tag 信 息 为 14.04。 


Docker Client 通 过 解析 remote 参 数 ， 使 得 remote 参 数 携带 
repository 信 息 和 tag 信 息 。Docker client 解析 remote 人 参数 的 第 一 
个 步 又 ， 源 码 如 下 : 


remote = cmd.Arg(0) 


其 中 ，cmd 的 第 一 个 参数 赋值 给 remote , 以 docker pull 
Ubuntu : 14.04 为 例 ,cmd.Arg( 0) 为 ubuntu : 14.04， 则 赋值 
后 remote 值 为 ubuntu : 14.04。 此 时 remote 参 数 不 仪 包含 Docker 
镜像 的 repository 人 信息， 人 还 包 含 tag 人 信息。 着用 户 请 求 中 市 有 Docker 
Registry 的 信息 , 如 docker pull localhost.localdomain : 
5000/dockerubuntu : 14.04 , cmd.Arg( 0) 为 
localhost.localdomain : 5000/docker/ubuntu : 14.04， 则 赋值 
后 remote 值 为 localhost.localdomain : 5000/docker/ubuntu : 
14.04 , 此 时 remote 参 数 同时 包含 Docker Registry 信 息 、 
repository 信 息 以 及 tag 信 息 。 


随后 ， 在 解析 remote 参 数 的 第 二 个 步骤 中 ，Docker Client 通 过 
解析 赋值 完毕 的 remote 参 数 解析 出 repository 信 息 ， 并 再 次 覆 写 
remote 参 数 的 值 ， 源 码 如 下 : 


remote, = parsers,ParseRepositoryTag (remote) 


ParseRepositoryTag 的 作用 是 : 解析 出 remote 参 数 的 
repository 信 息 和 tag 信 息 ， 该 水 数 的 实现 位 
于 ./docker/pkg/parsers/parsers.go#L72-L81 ,源码 如 下 : 


func ParseRepositoryTag(repos string) (string, string) { 
n := strings.LastIndex(repos, ":" 
ifn<0t{ 
return repos, "" 
} 


if tag := repos[n+1:]; !strings.Contains(tag, "/") { 
return repos[:n], tag 


return repos, "" 


} 


以 上 喘 数 的 实现 过 程 充 分 考虑 了 多 种 不 同 Docker Registry 的 情 
况 ， 如 : 请 求 docker pull ubuntu : 14.04 中 remote 参 数 为 
ubuntu : 14.04 , 而 请 求 docker pull localhost.localdomain : 
5000/docker/ubuntu : 14.04 中 用 户 指定 了 Docker Registry 的 地 
址 localhost.localdomain : 5000/docker , 故 remote 参 数 还 携带 


了 Docker Registry 信 息 。 


ParseRepositoryTag 顷 数 首先 从 repos 参 数 的 尾部 往 前 寻 
找 ”: ”, 若 不 存在 ， 则 说 明 用 户 没有 显 式 指定 Docker 镜 像 的 tag , 返 
回 整个 repos 作 为 Docker 镜 像 的 repository ; 车 ”:“ 存 在， 则 说 明 用 
户 显 式 指定 了 Docker 镜 像 的 tag ,“:“ 前 的 内 容 作为 repository 信 
息 ,“: “后 的 内 容 作 为 tag 信 息 ， 并 返回 两 者 。 


ParseRepositoryTag 国 数 执行 完 , 回 到 CmdPulI 纯 数 , 返回 内 
容 的 repository 信 息 将 履 写 remote 参 数 。 对 于 请 求 docker pull 
localhost.localdomain : 5000/dockerubuntu : 14.04 ,remote 
参数 被 履 写 后 ， 值 为 localhost.localdomain : 
5000/docker/ubuntu , 携带 Docker Registry 信 息 以 及 repository 


信息 。 
3. 配 置 url.Values 


Docker Client 发 送 请 求 给 Docker Server 时 ， 需 要 为 请 求 配置 
URL 的 查询 参数 。CmdPull 函 数 的 执行 过 程 中 创建 url.Value 并 配置 的 
源码 实现 位 于 ./docker/api/client/commands.go#L1194- 

L1203 , 如下: 


var ( 
V = url.Values{} 
remote = cmd.Arg(0) 


v.Set("fromImage", remote) 
if *tag == "" { 
v.Set("tag", *tag) 


其 中 ,变量 v 的 类 型 是 url.Values，, 最终 为 URL 配 置 的 查询 参数 有 
两 个 ,分别 为 fromlmage” 与 “tag”,“fromlmage” 的 值 是 remote 
参数 没有 被 覆 写 时 的 值 ,“tag" 的 值 一 般 为 空 ,原因 是 tag 参 数 已 弃 
用 ， 一 般 不 使 用 fag 参 数 tag。 


4. 解 析 hostname 人 参数 


Docker Client 解 析 镜 像 参数 时 ， 还 有 一 个 重要 的 环节 ， 那 就 是 
解析 Docker Registry 的 地 址 信息 。 若 用 户 希 望 从 指定 的 Docker 
Registry 中 下 载 Docker 镜 像 ， 则 Docker Client 需 要 考虑 这 种 情况 ， 
为 用 户 解析 出 Docker Registry 的 地 址 。 


解析 Docker Registry 地 址 的 代码 实现 位 
于 ./docker/api/client/commands.go#L1207 , 如下: 


hostname, , err := registry.ResolveRepositoryName(remote) 


Docker Client 通 过 包 registry 中 的 组 数 
ResolveRepositoryName 来 解析 hostname 参 数 ， 传 入 的 实 参 为 
remote , 即 去 tag 化 的 remote 参 数 。ResolveRepositoryName 史 | 
数 的 源码 实现 位 于 ./docker/registry/registry.go#L237-L259 ,如 
下 : 


func ResolveRepositoryName(reposName string) (string, string, error) { 
{ 


if strings.Contains(reposName, "://") 
// It cannot contain a scheme! 
return "", "", ErrIinvalidRepositoryName 
nameParts := strings.SplitN(reposName, "/", 2) 
if len(nameParts) == 
[|| (!strings.Contains(nameParts[0], ".") && !strings.Contains(nameParts[0], 
a ) && 
nameParts[0] != "localhost") { 
// This is a Docker Index repos (ex: samalba/hipache or ubuntu) 
err := validateRepositoryName (reposName) 


return IndexServerAddress(), reposName, err 


hostname := nameParts[0] 


reposName = nameParts[1] 
if strings.Contains(hostname, "index.docker.io") { 
return "", "", fmt.Errorf("Invalid repository name, try \"%s\" 
instead", reposName) 
} 


if err := validateRepositoryName(reposName); err != nil { 
return un ee un we 


return hostname, reposName, nil 


ResolveRepositoryName 隐 数 首先 通过 “/" 分 害 | 字 符 串 
reposName , 如 下 : 


nameParts := strings.SplitN(reposName, "/", 2) 


如 果 nameParts 的 长 度 为 1 , 则 说 明 reposName 中 不 含有 字 
符 “/”, 这 意味 着 用 户 没有 指定 Docker Registry。 另 外 , 形 
如 “samalba/hipache" 的 reposName 同 样 说 明 用 户 并 没有 指定 
Docker Registry ,其 中 samalba 为 用 户 在 Docker Hub 上 的 用 户 
名 。 当 用 户 没有 指定 Docker Registry 时 ，Docker Client 上 默认 返回 
IndexServerAddress( ) ， 该 函数 返回 常量 INDEXSERVER , 值 
为 “https://index.docker.io/v1”"。 也 就 是 说 , 当 用 户 下 载 Docker 镜 
像 时 ， 和 车 不 指定 Docker Registry， 上 默认 情况 下 ，Docker Client 通 
知 Docker Daemon 从 Docker Hub 上 下 载 镜像 。 例 如 : 请 求 docker 
pull ubuntu : 14.04 ,由 于 没有 指定 Docker Registry ,Docker 
Client 默 认 使 用 全 球 最 大 的 Docker Registry 一 一 Docker Hub。 


当 不 满足 返回 默认 Docker Registry 时 ，Docker Client 通 过 解 
析 reposNames , 得 出 用 户 指定 的 Docker Registry 地 址 。 例 如 : 请 
求 docker pull localhost.localdomain : 5000/dockerubuntu : 
14.04 中 ， 解 析出 的 Docker Registry 地 址 为 


localhost.localdomain : 5000, 


至 此 ,与 Docker 镜 像 相 关 的 参数 已 经 全 部 解析 完毕 ，Docker 
Client 将 携带 这 部 分 重要 信息 以 及 用 户 的 认证 信息 来 构建 RESTful 请 
求 ， 发 送 给 Docker Server。 


9.3.2 ”配置 认证 信息 


用 户 下 载 Docker 镜 像 时 ，Docker 同 样 支持 用 户 信息 的 认证 。 用 
户 认 证 信息 由 Docker Client 配 置 ; Docker Client 发 送 请 求 至 
Docker Server 时 ， 用 户 认证 信息 也 被 一 并 发 送 ; 随后 ,Docker 
Daemon 处 理 下 载 Docker 镜 像 的 请 求 时 ， 用 户 认证 信息 将 在 Docker 
Registry 中 验证 。 


Docker Client 配 置 用 户 认 证 信息 包含 两 个 步 又， 实现 源码 如 下 : 


cLi.LoadConfigFiLe() 
// Resolve the Auth config relevant for this server 
authConfig := cli.configFile.ResolveAuthConfig(hostname) 


可 见 ， 第 一 个 步 又 是 使 cli( Docker Client) 加 载 ConfigFile ， 
ConfigFile 是 Docker Client 用 于 存放 用 户 在 Docker Registry 上 认证 
言 息 的 对 象 。DockerCli、ConfigFile 以 及 AuthConfig 三 种 数据 结构 
之 间 的 关系 如 图 9-2 所 示 。 
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9-2 DockerCli、ConfigFile 以 及 AuthConfig 关 系 图 


DockerCli 结 构 体 的 属性 configFile 是 一 个 指向 
registry.ConfigFile 的 指针 ， 而 ConfigFile 结 构 体 的 属性 Configs 属 于 
map 类 型 ,其 中 key 为 string, 代表 Docker Registry 的 地 址 ,value 
的 类 型 为 AuthConfig。AuthConfig 类 型 的 具体 含义 为 用 户 在 某 个 
Docker Registry 上 的 认证 信息 ， 包含 用 户 名 、 密 码 、 认 证 信息 、 邮 
箱 地 址 以 及 服务 医 地 址 等 。 


加 载 完 用 户 所 有 的 认证 信息 之 后 ,Docker Client 配 置 用 户 认证 信 
息 的 第 二 个 步 又 是 : 通过 用 户 指定 的 Docker Registry， 即 之 前 解析 
出 的 hostname 参 数 ， 从 用 户 所 有 的 认证 信息 中 找 出 与 指定 
hostname 相 匹配 的 认证 信息 。 新 创建 的 authConfig ,类 型 即 为 
AuthConfig , 将 会 作为 用 户 在 指定 Docker Registry 上 的 认证 信息 ， 
发 送 至 Docker Server。 


9.3.3 发送 API 请 求 


解析 完 所 有 的 Docker 镜 像 参数 ， 并 且 配 置 完毕 用 户 的 认证 信息 之 
后 ,Docker Client 需 要 使 用 这 些 信息 正式 发 送 镜像 下 载 的 请 求 至 


Docker Server 。 


Docker Client 定 义 了 pull 闹 数 来 实现 发 送 镜 像 下 载 请 求 至 
Docker Server , 源码 位 
于 ./docker/api/client/commands.go#L1217-L1229 , 如下: 


pull := func(authConfig registry.AuthConfig) error { 
buf, err := json.Marshal (authConfig) 
if err != nil { 
return err 
} 


registryAuthHeader := []string{ 
base64 .URLEncoding.EncodeToString(buf), 


return cli.stream("POST", "/images/create?"+v.Encode(), nil, cli.out, 
map[string][]string{ 
"X-Registry-Auth": registryAuthHeader, 
}) 


pull 包 数 的 实现 较为 简单 ， 首 先 通过 authConfig 对 象 创建 
registryAuthHeader , 最 后 发 送 POST 请 求 ， 请 求 的 URL 
为 “/images/create ? "+V.Encode( ) ,在 URL 中 传 入 查询 参数 ， 
包括 “fromlmage” 与 “tag”, 另外 在 请 求 的 HTTP Header 中 添加 认 
证 信息 registryAuthHeader。 


执行 以 上 pull 孙 数 时 ，Docker 镜 像 下 载 请 求 被 发 送 ， 随 后 
Docker Client 等 待 Docker Server 的 接收 、 处 理 与 响应 ， 


9.4 Docker Server 


Docker Server 作 为 Docker Daemon 的 入 口 ， 所 有 Docker 
Client 发 送 请 求 都 由 Docker Server 接 收 。Docker Server 通 过 解析 
请 求 的 URL 与 请 求 方法 ， 最终 路 由 分 发 至 相应 的 处 理 方法 来 处 理 。 
Docker Server 的 创建 与 请 求 处 理 可 以 参见 第 5 章 。 


Docker Server 接 收 到 镜像 下 载 请 求 之 后 ， 通 过 路 由 分 发 最 终 由 
具体 的 处 理 方法 一 一 postlImagesCreate 来 处 理 。 
postlImagesCreate 的 源码 实现 位 
于 ./docker/api/server/server.go#L466-L524 , 其 执行 流程 主要 分 
为 3 部 分 : 


1) 解析 HTTP 请 求 中 包含 的 请 求 参 数 ， 包 括 URL 中 的 查询 参数 、 
HTTP Header 中 的 认证 信息 等 ; 


2) 创建 镜像 下 载 Jjob， 并 为 该 job 配置 环境 变量 ， 


3) 触发 执行 镜像 下 载 Job。 


9.4.1 解析 请 求 参 数 


Docker Server 接 收 到 Docker Client 发 送 的 镜像 下 载 请 求 之 
后 ， 首 先 解析 请 求 参数 ， 并 为 后 续 jJob 的 创建 与 运行 提供 参数 依据 。 
Docker Server 解 析 的 请 求 参数 主要 有 HTTP 请 求 URL 中 的 查询 参 
数 “fromlmage” “repo" 以 及 “tag”, 还 有 HTTP 请 求 Header 中 
的 “X-Registry-Auth ”。 


请 求 参 数 解析 的 源码 如 下 : 


Var ( 
image = r.Form.Get("fromImage") 
repo = r.Form.Get("repo") 
tag = r.Form.Get ("tag") 
job  *engine.Job 


) 
authEncoded := r.Header.Get("X-Registry-Auth") 


需要 特别 说 明 的 是 ， 通 过 “fromlmage” 解 析出 的 image 变 量 包 
含 镜像 repository 名 称 与 镜像 tag 信 息 。 例 如， 各 用 户 请 求 为 docker 
pull ubuntu : 14.04， 则 通过 “fromlmage” 解 析出 的 image 变 量 值 
为 Ubuntu : 14.04， 并非 只 有 Docker 镜 像 的 名 称 。 


另外 , Docker Server 通 过 从 HTTP Header 中 解析 出 
authEncoded , 还 原 出 类 型 为 registry.AuthConfig 的 对 象 
authConfig ,源码 实现 如 下 : 


authConfig := &registry.AuthConfig{} 


if authEncoded != "" { 
authJson := base64.NewDecoder(base64.URLEncoding, strings.NewReader 
(authEncoded)) 
if err := json.NewDecoder(authJson).Decode(authConfig); err != nil { 


// for a pull it is not an error if no auth was given 
// to increase compatibility with the existing api it is 
defaulting to be empty 
authConfig = &registry.AuthConfig{} 
} 


} 


解析 出 HTTP 请 求 中 的 参数 之 后 ，Docker Server 对 于 image 参 
数 绸 次 进行 解析 ， 从 中 解析 出 属于 镜像 的 repository 与 tag 信 息 ， 其 
中 repository 有 可 能 暂时 包含 Docker Registry 信 息 ， 源 码 实现 如 
下 : 


if tag == "" { 
image, tag = parsers.ParseRepositoryTag (image) 


Docker Server 的 参数 解析 工作 至 此 全 部 完成 ， 之 后 Docker 
Server 将 创建 镜像 下 载 任务 并 开始 执行 。 


9.4.2 创建 并 配置 Job 


Docker Server 只 负责 接收 Docker Client 发 送 的 请 求 ， 并 将 其 
路 由 分 发 至 相应 的 处 理 方法 来 处 理 ， 最 终 的 请 求 执行 还 需要 Docker 
Daemon 来 协作 完成 。Docker Server 在 处 理 方 法 中 ,通过 创建 job 
并 触发 job 执行 的 形式 ， 把 控制 权 交 给 Docker Daemon。 


Docker Server 创 建 镜像 下 载 job 并 配置 环境 变量 的 源码 实现 如 
下 : 


job = eng.Job("pull", image, tag) 
job.SetenvBool("parallel", version.GreaterThan("1.3")) 


job.Setenvjson("metaHeaders", metaHeaders) 
job.SetenvjJson("authConfig", authConfig) 


其 中 ， 创 建 的 job 名 为 pull , 含义 是 下 载 Docker 镜 像 ， 传 入 参数 
为 image 与 tag， 配置 的 环境 变量 有 parallel、metaHeaders 与 
authConfig, 


9.4.3 触发 执行 job 


Docker Server 创 建 完 Docker 镜 像 下 载 Job 之 后 ， 需 要 触发 该 
job 执行 ， 实 现 将 控制 权 交 给 Docker Daemon。 


Docker Server 触 发 执行 job 的 源码 如 下 : 


if err := job.Run(); err != nil { 
if !job.Stdout.Used() { 
return err 
} 
sf := utils.NewStreamFormatter(version.GreaterThan("1.0")) 


w.Write(sf.FormatError(err)) 


} 


由 于 Docker Daemon 在 启动 时 , 已 经 配置 了 名 为 “pull 的 job 所 
对 应 的 处 理 方法 ， 实 际 为 graph 包 中 的 CmdPull 范 数 ， 故 一 旦 该 job 
被 触发 执行 ， 控 制 权 将 直接 交 给 Docker Daemon 的 CmdPull 邹 数 。 
Docker Daemon 启 动 时 Engine 的 处 理 方法 注册 可 以 参见 第 3 章 。 


9.5 Docker Daemon 


Docker Daemon 是 完成 job 执行 的 主要 载体 。Docker Server 
为 镜像 下 载 Job 准 备 好 所 有 的 参数 配置 之 后 , 只 等 Docker Daemon 
来 完成 执行 ， 并 返回 相应 的 信息 ，Docker Server 再 将 响应 信息 返回 
至 Docker Client。Docker Daemon 对 于 镜像 下 载 Job 的 执行 涉及 的 
内 容 较 多 : 首先 解析 job 参数 ， 获 取 Docker 镜 像 的 repository、tag 
以 及 Docker Registry 信 息 等 ; 随后 与 Docker Registry 建 立会 话 
( sessiom) ; 然后 通过 会 话 下 载 Docker 镜 像 ; 接着 将 Docker 镜 像 
下 载 至 本 地 并 存储 于 Graph 中 ; 最 后 在 TagStore 中 标记 该 镜像 。 


Docker Daemon 对 于 镜像 下 载 job 的 执行 主要 依靠 CmdPull 狗 
数 。 这 个 CmdPulIl 函 数 与 Docker Client 的 CmdPull 函 数 完全 不 同 ， 
前 者 是 为 了 代替 用 户 发 送 镜 像 下 载 的 请 求 至 Docker Daemon ,而 
Docker Daemon 的 CmdPul| 销 数 则 实现 代替 用 户 真正 完成 镜像 下 载 
的 任务 。 调 用 CmdPull 喘 数 的 对 象 类 型 为 T9gStore , 其 源码 实现 位 
于 ./dockervgraph/pull.go。 


9.5.1 解析 job 参数 


正如 Docker Client 与 Docker Server 一 样 , Docker Daemon 执 
镜像 下 载 Jjob 时 的 第 一 个 步 又 也 是 解析 参数 。 解 析 工 作 一 方面 要 确保 
传 入 参数 无 误 ， 另 一 方面 也 要 按 需 为 Job 提 供 参 数 依据 。 表 9-1 罗 列 出 
Docker Daemon 和 解析 的 Job 参 数 。 


表 9-1 Docker Daemon 解 析 的 Job 参 数 


























参数 名 称 参数 描述 
localName 代表 镜像 的 repository 信息 ， 有 可 能 携带 Docker Registry 信息 
tag 代表 镜像 的 标签 信息 默认 为 latest 
authConfig 代表 用 户 在 指定 Docker Registry 上 的 认证 信息 
metaHeaders 代表 请 求 中 的 HTTP Header 信息 
hostname 代表 Docker Registry 信息 ， 从 localName 解析 获得 ， 默 认为 Docker Hub 地 址 
remoteName 代表 Docker 镜像 的 repository 名 称 信息 ， 不 携带 Docker Registry 信息 
endpoint 代表 Docker Registry 完整 的 URL， 从 hostname 扩展 获得 





参数 解析 过 程 中 ，Docker Daemon 还 添加 了 一 些 精 妙 的 设计 。 
如 : 在 TagStore 类 型 中 设计 了 pullingPool 对 象 ， 用 于 保存 正在 下 载 的 
Docker 镜 像 ， 下 载 完毕 之 前 茶 止 其 他 Docker Client 发 起 相同 镜像 的 
下 载 请 求 ， 下 载 完 毕 之 后 pullingPool 中 的 该 记录 被 清除 。Docker 
Daemon 一 旦 解析 出 localName 与 tag 两 个 参数 信息 ， 就 立即 检测 
pullingPool , 源码 实现 位 于 ./docker/graph/pull.go#L36-L46 ,如 
下 : 


c, err := Ss.poolAdd("pull", localName+":"+tag) 
if err != nil { 
if c != nil { 
// Another pull of the same repository is already taking place; 
just wait for it to finish 
job.Stdout.Write(sf,.FormatStatus("", "Repository %s already being 
pulled by another client. Waiting.", localName)) 
<-C 
return engine.StatusOK 
} 
return job.Error(err) 


} 


defer s.poolRemove("pull", localName+":"+tag) 


9.5.2 创建 Session 对象 


为 了 下 载 Docker 镜 像 ，Docker Daemon 与 Docker Registry 需 
要 建立 通信 。 为 了 保障 两 者 之 间 通 信 的 可 靠 性 ，Docker Daemon 采 
用 了 session 机 制 。Docker Daemon 每 收 到 一 个 Docker Client 的 镜 
像 下 载 请 求 ， 都 会 创建 一 个 与 之 相应 的 Docker Registry 的 
session , 之 后 所 有 的 网 络 数据 传输 都 在 该 Session 上 完成 。 包 
registry 定 义 了 session , 位 于 ./docker/registry/registry.go , 如 
下 : 


type Session struct { 
authConfig *AuthConfig 
reqFactory *utils.HTTPRequestFactory 
indexEndpoint string 
jar *cookiejar.Jar 
timeout TimeoutType 


CmdPulI 锁 数 中 创建 session 的 源码 实现 如 下 : 


r, err := registry.NewSession(authConfig, 
registry.HTTPRequestFactory (metaHeaders), endpoint, true) 


创建 的 session 对 象 为 r ,在 执行 镜像 下 载 过 程 中 ， 多 数 与 镜像 相 
关 的 数据 传输 均 在 r 这 个 seesion 的 基础 上 完成 。 


9.5.3 执行 镜像 下 载 


数 ， 
I 


十 上 


Docker Daemon 之 前 所 有 的 操作 都 属于 配置 阶段 ， 从 解析 Job 参 
到 建立 session 对 象 ， 而 并 未 与 Docker Registry 建 立 实 际 的 连 
并 且 也 还 未 真正 传输 过 有 关 Docker 镜 像 的 内 容 。 


完成 所 有 的 配置 之 后 ，Docker Daemon 进入 Docker 镜 像 下 载 环 


, 实现 Docker 镜 像 的 下 载 ， 源 码 位 


于 ./docker/graph/pull.go#L69-L71 , 如下: 


if err = s.pullRepository(r, job.Stdout, localName, remoteName, tag, sf, 
job.GetenvBool ("parallel")); err != nil { 


return job.Error(err) 


以 上 代码 中 pullRepository 哨 数 包含 了 镜像 下 载 整 个 流程 的 林 林 


总 总 ? 下 载 流程 如 图 9-3 所 示 。 


r. GetRepositoryData() 
| r. GetRemoteHistory() 


r. GetRemoteTags () | 
r. pullImage() | 
| r. GetRemote ImageLayer () 


s. graph. Register () 


图 9-3 pullRepository 中 镜像 下 载 的 流程 图 
图 9-3 中 各 个 环节 的 简要 功能 介绍 见 表 9-2。 


表 9-2 pullRepository 各 环节 功能 























函数 名 称 功能 介绍 
LGetRepositoryData() 获取 指定 repository 中 所 有 镜像 的 ID 信息 
r.GetRemoteTags() 获取 指定 repository 中 所 有 的 tag 信息 
r.pullImage() 从 Docker Registry 下 载 Docker 镜像 
r.GetRemoteHistory|O 获取 指定 image 所 有 祖先 镜像 的 ID 信息 
r.GetRemoteImageJSON() 获取 指定 image 的 json 信息 
r.GetRemoteImageLayer() 获取 指定 image 的 layer 信息 
s.graph.Register() 将 下 载 的 镜像 在 TagStore 的 graph 中 注册 
s.SetO) 在 TagStore 中 添加 新 下 载 的 镜像 信息 


分 析 pullRepository 的 整个 流程 之 前 ， 我们 有 必要 了 解 
pullRepository 呢 数 调 用 者 的 类 型 TgStore。TagStore 是 Docker 镜 
像 方面 涵盖 内 容 最 多 的 数据 结构 : 一 方面 但 gStore 管 理 Docker 的 


Graph， 另 一 方面 TagStore 还 管理 Docker 的 repository 记 录 。 除 此 
之 外 ，TagStore 还 管理 4.6.7 节 提 到 的 对 象 pullingPool 以 及 
pushingPool , 保证 Docker Daemon 在 同一 时 刻 只 为 一 个 Docker 
Client 执 行 同一 镜像 的 下 载 或 上 传 。TagStore 结 构 体 的 定义 位 

于 .,/docker/graph/tags.go#L20-L29 , 如 下 : 


type TagStore struct { 
path string 
graph *Graph 
Repositories map[string]Repository 
sync.Mutex 
// FIXME: move push/pull-related fields 
// to a helper type 
pullingPool map[string]chan struct{} 
pushingPool map[string]chan struct{} 


下 面 将 重点 分 析 pullRepository 的 整个 流程 。 
1.GetRepositoryData 


使 用 Docker 下 载 镜像 时 ， 用 户 往往 指定 的 是 Docker 镜 像 的 名 
称 ， 如 : 请 求 docker pull ubuntu : 14.04 中 镜像 名 称 为 Ubuntu。 
GetRepositoryData 的 作用 则 是 获取 镜像 名 称 所 在 repository 中 所 有 


image 的 ID 信息 。 


GetRepositoryData 的 源码 实现 位 
于 ./docker/registry/session.go#L255-L324。 获 取 repository 中 
image 的 id 信 息 的 目 标 URL 地 址 的 源码 如 下 : 


repositoryTarget := fmt.Sprintf("%srepositories/%s/images", indexEp, remote) 


因此 ，docker pull ubuntu : 14.04 请 求 被 执行 时 ，repository 
的 目 标 URL 地 址 为 
https: //index.docker.io/v1l/repositories/ubuntu/images ,访问 该 
URL 可 以 获得 有 关 ubuntu 这 个 repository 中 所 有 image 的 ID 信息 , 首 
分 image 的 ID 信息 如 下 : 


[{"checksum": Ss "id": 
"2427658c75ale3d0af0e7272317a8abfaee4c13729b6840e3c2fca342fe47bf1” }, {"checksum": 
"", "id" 和 }, 

{" Checksum" p 

rec6 9e8 fd6b0236b67227869b6d6d1191033221dd0f01e0f569518edabef3b72c" }, {"checksum": 
pe lo lh 0 }, 

{" Checksum" " 
"78949blelcfdcdsdb413c360923b178fc4b59cge417221cgeb2ffbbd1a4725ccs 有 ] 


获取 以 上 信息 之 后 ,Docker Daemon 通 过 RepositoryData 和 
ImgData 类 型 对 象 来 存储 ubuntu 这 个 repository 中 所 有 image 的 信 
息 , RepositoryData 和 ImgData 中 数据 结构 的 关系 如 图 9-4 所 示 。 


RepositoryData 
ImgList map[string]*ImgData ImgData 


Endpoints [jstring 
Tokens [] string string 
string 









ChecksumPayload string 
Tag string 


图 9-4 RepositoryData 和 ImgData 中 数据 结构 的 关系 


GetRepositoryData 执 行 过 程 中 ， 会 为 指定 repository 中 的 每 一 
个 image 创 建 一 个 ImgData 对 象 ， 并 最 终 将 所 有 ImgData 存 放 在 
RepositoryData 的 ImgList 属 性 中 ，lmgList 的 类 型 为 map ,， key 为 
image 的 ID ,value 指 向 ImgData 对 象 。 此 时 ImgData 对 象 中 只 有 属 
性 ID 与 Checksum 有 内 容 。 


2.GetRemoteTags 


使 用 Docker 下 载 镜像 时 ， 用 户 除了 指定 Docker 镜 像 的 名 称 之 
外 ， 一 般 还 需要 指定 Docker 镜 像 的 tag, 如 : 请 求 docker pull 
ubuntu : 14.04 中 镜像 名 称 为 Upuntu， 镜 像 tag 为 14.04， 假 设 用 户 
不 显 式 指定 tag , 则 默认 tag 为 latest。GetRemoteTags 的 作用 则 是 
获取 镜像 名 称 所 在 repository 中 所 有 tag 的 信息 。 


GetRemoteTags 的 源码 实现 位 
于 ./dockerregistry/session.go##L195-234。 获 取 repository 中 所 
有 tag 信 息 的 目标 URL 地 址 的 源码 如 下 : 


endpoint := fmt.Sprintf("%srepositories/%s/tags", host, repository) 


获取 指定 repository 中 的 所 有 tag 信 息 之 后 , Docker Daemon 根 
据 tag 对 应 layer 的 ID ,找到 ImgData ,并 填充 ImgData 中 的 Tag 属 
性 。 此 时 ，RepositoryData 的 ImgList 属 性 中 ， 有 的 ImgData 对 和 象 中 
有 Tag 内 容 , 有 的 ImgData 对 象 中 没有 Tag 内 容 。 这 也 和 实际 情况 相 


符 ， 如 果 下 载 一 个 ubuntu : 14.04 镜 像 ， 该 镜像 的 rootfs 中 只 有 最 上 
层 的 layer 才 有 tag 信 息 ， 这 一 个 layer 的 父 镜 像 并 不 一 定 存在 tag 信 


自 


3.pulllmage 


Docker Daemon 下 载 Docker 镜 像 是 通过 镜像 ID 来 完成 的 。 
GetRepositoryData 和 GetRemoteTags 则 成 功 完 成 了 用 户 传 入 的 
repository 和 tag 信 息 与 镜像 ID 之 间 的 转换 。 如 请 求 docker pull 
ubuntu : 14.04 中 ，repository 为 ubuntu ,tag 为 14.04， 则 对 应 的 
镜像 ID 为 2d24f826。 需 要 注意 的 是 ,ubuntu : 14.04 镜 像 的 layer 并 
不 是 一 成 不 变 的 ，Docker Hub 上 关于 该 镜像 的 内 容 仍 然 会 更 新 。 


Docker Daemon 获 得 下 载 镜像 的 镜像 ID 之 后 ， 首 先 查 验 
pullingPool , 判断 是 否 有 其 他 Docker Client 同 样 发 起 了 该 镜像 的 下 
载 请 求 ， 若 没有 Docker Daemon 才 继续 下 载 任务 。 


执行 pulllmage 蚊 数 的 源码 实现 位 
于 ./docker/graph/pull.go#L159 ,如 下 : 


s.pullImage(r, out, img.ID, ep, repoData.Tokens, sf) 


而 pulllmage 也 数 的 定义 位 于 ./docker/graph/pull.go#L214- 
L301。 图 9-3 中 ， 我 们 可 以 看 到 pulllmage 函 数 的 执行 可 以 分 为 4 个 步 


又 : GetRemoteHistory、GetRemotelmagejSON.、 
GetRemotelmageLayer 与 s.graph.Register ) 。 


GetRemoteHistory 的 作用 很 好 理解 ， 既 然 Docker Daemon 已 
经 通过 GetRepositoryData 和 GetRemoteTags 找 出 了 指定 tag 的 
image id , 那么 Docker Daemon 所 需 完 成 的 工作 为 下 载 该 image 及 
其 所 有 的 祖先 image。GetRemoteHistory 负 责 获 取 指 定 image 及 其 
所 有 祖先 image 的 id。 


GetRemoteHistory 的 源码 实现 位 
于 ./docker/registry/session.go#L72-L101, 


获取 所 有 的 image id 之 后 ， 对 于 每 一 个 image id ,Docker 
Daemon 都 开始 下 载 该 image 的 全 部 内 容 。 一 个 layer 的 Docker 
Image 包 括 两 个 方面 的 内 容 : image json 信 息 以 及 image layer 信 
息 。Docker 所 有 image 的 json 信 息 都 由 滔 数 
GetRemotelmagejSON 来 获取 。 分 析 GetRemotelmagejSON 之 
前 ， 有 必要 阐述 清 芭 什么 是 Docker Image 的 json 信 息 。 


Docker Image 的 json 信 息 是 一 个 非常 重要 的 概念 。 这 部 分 json 
唯一 标志 一 个 image , 不 仅 标 志 image 的 id ， 还 标志 image 所 在 layer 
对 应 的 config 配 置信 息 。 为 了 理解 以 上 内 容 ， 可 以 举 一 个 例子 : 
docker build。 命令 docker build 用 于 通过 指定 的 Dockerfile 来 创建 


一 个 Docker 镜 像 ; 对 于 Dockerfile 中 所 有 的 命令 ,Docker Daemon 
都 会 为 其 创建 一 个 新 的 image ,如 :RUN apt-get update ，ENV 
path=/bin, WORKDIR/home 等 。 对 于 命令 RUN apt-get 

update , Docker Daemon 需 要 执行 apt-get update 操 作 ， 对 应 的 
rootfs 上 必定 会 有 内 容 更 新 ， 导 致 新 建 的 image 所 代表 的 layer 中 有 新 
添加 的 内 容 。 而 如 ENV path=/bin ,WORKDIR/home 这 样 的 命令 ， 
仅仅 配置 了 一 些 容 北 的 运行 参数 ， 并 没有 镜像 内 容 的 更 新 ， 对 于 这 种 
情况 ，Docker Daemon 同 样 创建 一 个 新 的 layer ,并 且 这 个 新 的 
layer 中 内 容 为 空 ， 而 命令 内 容 会 在 这 层 image 的 json 信 息 中 做 更 新 。 
总 之 ， 可 以 认为 Docker 的 image 包 含 两 部 分 内 容 :image 的 json 信 
息 、layer 内 容 。 当 layer 内 容 为 空 时 , image 的 json 信 息 被 更 新 。 第 
11 章 将 重点 分 析 Docker 中 dockerbuild 的 实现 。 


清楚 Docker image 的 json 信 息 之 后 ， 理 解 
GetRemotelmageJSON 哨 数 的 作用 就 变 得 十 分 容易 。 执 行 
GetRemotelmagejSON 的 源码 实现 位 
于 .,/docker/graph/pull.go#L243 , 如 下 : 


imgJSON, imgSize, err = r.GetRemoteImageJSON(id, endpoint, token) 


GetRemotelmagejSON 返 回 的 对 象 imgjSON 代 表 image 的 json 
信息 ,imgSize 代 表 镜 像 的 大 小 。 通 过 imgjSON 对 象 ，Docker 


Daemon 立 即 创建 一 个 image 对 象 ， 创 建 image 对 象 的 源码 实现 位 
于 ./docker/graph/pull.go#L251 , 如下: 


img, err = image.NewImgJSON(imgJSON) 


而 NewlmgjSON 贞 数 位 于 包 image 中 ， 上 数 返回 类 型 为 一 个 
Image 对 象 ,Image 类 型 的 定义 如 下 : 


type Image struct { 
ID 


string ”json:" id” 
Parent string “json:"parent,omitempty". 
Comment string ~ json:"comment,omitempty" 
Created time.Time “json:"created". 
Container string json: "container, Oomitempty 
ContainerConfig runconfig.Config “json:! 'container config, omitempty" 
DockerVersion string ‘json:"docker version, omitempty" 
Author string “json:"author,omitempty" 
Config *runconfig.Config ‘json:"config,omitempty"、 
Architecture string “json:"architecture,omitempty" 
0S string “json:"os,omitempty". 
Size int64 


graph Graph 


返回 img 对 象 ， 则 说 明 关 于 该 image 的 所 有 元 数据 已 经 保存 完 
毕 ， 由 于 还 缺少 mage 的 layer 中 包含 的 内 容 ， 因 此 下 一 个 步骤 即 为 下 
载 镜像 layer 的 内 容 ， 调用 的 水 数 为 GetRemotelmageLayer , 函数 
的 源码 位 于 ./docker/graph/pull.go#L270 , 如下: 


layer, err := r.GetRemoteImageLayer(img.ID, endpoint, token, int64 (imgSize)) 


GetRemotelmageLayen 溪 数 返 回 当 前 image 的 layer 内 容 。 
image 的 layer 内 容 指 的 是 : 该 image 在 parent image 之 上 做 的 文件 


系统 内 容 更 新 ， 包 括 文 件 的 增添 、 删 除 、 修 改 等 。 至 此 ,image 的 
json 信 息 以 及 layer 内 容 均 被 Docker Daemon 获取， 这 意味 着 一 个 完 
整 的 image 已 经 下 载 完毕 。 下 载 image 完 毕 之 后 ， 并 不 意味 着 Docker 
Daemon 关 于 Docker 镜 像 下载 的 job 就 此 结束 ，Docker Daemon 仍 
汰 需要 对 下 载 的 image 进 行 存储 管理 ， 以 便 Docker Daemon 在 执行 
其 他 ( 如 创建 容 莫 等 ) job 时 ， 能 够 方便 地 使 用 这 些 image。 


Docker Daemon 在 graph 中 注册 image 的 源码 实现 位 
于 ./docker/graph/pull.go#L283-L285 , 如 下 : 


err = s.graph.Register(imgJSON,utils.ProgressReader(layer, imgSize, out, sf, 
false, utils.TruncateID(id), "Downloading"),img) 


Docker Daemon 通 过 graph 存 储 image 是 一 个 很 重要 的 环节 。 
Docker 在 1.2.0 版 本 中 可 以 通过 aufs、DevMapper 以 及 BTRFS 来 进 
行 image 的 存储 。 在 Linux 3.18-rc2 版 本 中 ,OverlayFS 已 经 被 合 入 
内 容 主线 ， 故 从 Docker 1.4.0 版 本 开始 , Docker 的 image 支 持 
OverlayFS 的 存储 方式 。 


Docker 镜 像 的 存储 在 Docker 中 是 较为 独立 日 重要 的 内 容 , 第 10 
章 将 对 Docker 镜 像 的 存储 进行 深入 分 析 。 


4. 配 置 TagStore 


Docker 镜 像 下 载 完 毕 之 后 , Docker Daemon 需 要 在 TagStore 中 
指定 的 repository 中 添加 相应 的 tag。 每 当 用 户 查 看 本 地 镜像 时 ， 都 可 
以 从 TegsStore 的 repository 中 查看 所 有 含 tag 信 息 的 image。 


Docker Daemon 配 置 TagStore 的 源码 实现 位 
于 .,/docker/graph/pull.go#L206 , 如 下 : 


if err := S.9et(LocaLName，tag，id，true); err != nil { 
return err 
} 


TagStore 类 型 的 Set 函 数 定义 位 
于 ./dockergraph/tags.go##L174-L205。Set 级 数 的 执行 流程 与 简 
要 介绍 如 图 9-5 所 示 。 
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查看 Graph 中 是 否 确定 存在 指定 image 


验证 repository 的 名 称 是 否 合 法 
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加 载 本 地 的 repository 文 件 ， 
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在 repository 对 象 中 添加 新 镜像 
的 tag 信 息 以 及 image id 


保存 repository 人 信息， 持久 化 


store, save () 
( 到 Docker Daemon 本 地 


9-5 TagStore 中 Set 员 数 的 执行 流程 及 简介 


当 Docker Daemon 将 已 下 载 的 Docker 镜 像 信息 同步 到 
repository 之 后 ，Docker 下 载 镜像 的 J]ob 就 全 部 完成 ，Docker 
Daemon 返 回响 应 至 Docker Server , Docker Server 返 回响 应 至 
Docker Client。 本 地 的 repository 文 件 位 于 Docker 的 根 目录 ， 根 目 


录 一 般 为 /varlib/docker , 如 果 使 用 aufs 的 graphdriver， 则 
repository 文 件 名 为 repositories-aufs。 


9.6 总 结 


Docker 镜 像 给 Docker 容 希 的 运行 带 来 了 无 限 的 可 能 性 ， 诸 如 
Docker Hub 之 类 的 Docker Registry 又 使 得 Docker 镜 像 在 全 球 的 开 
发 者 之 间 共 享 。Docker 镜 像 的 下 载 是 使 用 Docker 的 第 一 个 步 又。 
Docker 爱 好 者 若 能 熟练 掌握 其 中 的 原理 ， 必定 能 对 Docker 的 很 多 概 
念 有 更 为 清晰 的 认识 ， 对 Docker 容 器 的 运行 、 管 理 等 均 是 有 百 利 而 无 
一 害 。 

Docker 镜 像 的 下 载 需要 Docker Client、Docker Server、 
Docker Daemon 以 及 Docker Registry 四 者 协同 合作 完成 。 本 章 从 
源码 的 角度 分 析 了 四 者 各 自 扮演 的 角色 ， 分 析 过 程 中 还 涉及 多 种 
Docker 概 念 ， 如 repository、tag、TagStore、session、image.、 


layer、image json 和 graph 等 。 


第 10 曹 ”Docker 镜 像 存 储 


10.1 引言 


Docker Hub 汇 总 众多 Docker 用 户 的 镜像 ， 极 大 地 发 挥 Docker 
镜像 开放 的 思想 。Docker 用 户 在 全 球 任 意 一 个 位 置 ， 都 可 以 与 
Docker Hub 交互， 分享 自己 构建 的 镜像 至 Docker Hub , 当然 , 也 
完全 可 以 下 载 另 一 半球 Docker 开 发 者 上 传 至 Docker Hub 的 Docker 
镜像 。 


无 论 是 上 传 ， 还 是 下 载 Docker 镜 像 ， 镜 像 必 然 都 会 以 某 种 形式 存 
储 在 Docker Daemon 所 在 的 宿主 机 文件 系统 中 。 关 于 Docker 镜 像 
在 宿主 机 中 的 存储 ， 关 键 点 在 于 : 在 本 地 文件 系统 中 以 何 种 组 织 形式 
被 Docker Daemon 有 效 地 统一 化 管理 。 这 种 管理 可 以 使 得 Docker 
Daemon 创 建 Docker 容 颖 服务 时 ，, 方便 获取 镜像 并 完成 Union 
Mount 操 作 ， 为 容 莫 准备 初始 化 的 文件 系统 。 


本 章 主 要 从 Docker 1.2.0 源 码 的 角度 ， 分析 Docker Daemon 下 
载 镜像 过 程 中 存储 Docker 镜 像 的 环节 。 本 章 分 析 的 内 容 有 以 下 5 部 
分 : 


1) 概述 Docker 镜 像 存储 的 执行 人口， 并 简要 介绍 存储 流程 的 四 


个 步 又 ; 
2) 验证 镜像 ID 的 有 效 性 ; 
3) 创建 镜像 存储 路 径 ; 
4) 存储 镜像 内 容 ; 


5) 在 Graph 中 注册 镜像 ID。 


10.2 镜像 注册 


Docker Daemon 执 行 镜像 下 载 任 务 时 ， 从 Docker Registry 处 
下 载 指 定 镜 像 之 后 ， 仍 需要 将 镜像 合理 地 存储 于 宿主 机 的 文件 系统 
中 。 更 为 具体 而 言 ， 存储 工作 分 为 两 个 部 分 : 


1) 存储 镜像 内 容 ; 
2) 在 Graph 中 注册 镜像 信息 。 


提 到 镜像 内 容 ， 需 要 强调 的 是 ,每 一 个 layer 的 Dockerlmage 内 
容 都 可 以 认为 由 两 个 部 分 组 成 : 镜像 中 每 一 个 layer 中 存储 的 文件 系统 
内 容 ， 这 部 分 内 容 一 般 可 以 认为 是 未 来 Docker 容 闫 的 静态 文件 内 容 ; 
另 一 部 分 内 容 指 的 是 容 闫 的 json 文 件 , json 文 件 代表 的 信息 除了 容 善 
的 基本 属性 信息 之 外 ， 还 包括 未 来 容 比 运行 时 的 动态 信息 ， 如 ENV 等 


主 自 
信息 。 


存储 镜像 内 容 ， 意 味 着 Docker Daemon 所 在 簿 主机 上 已 经 存在 
镜像 的 所 有 内 容 ， 除 此 之 外 ,Docker Daemon 仍 需要 对 所 存储 的 镜 
像 进行 统计 备案 ， 以 便 用 户 在 后 续 的 镜像 管理 与 使 用 过 程 中 ,可 以 有 
据 可 循 。 为 此 , Docker Daemon 设 计 了 Graph，, 使 用 Graph 来 接管 
这 部 分 的 工作 。Graph 负 责 记 录 有 哪些 镜像 已 经 正确 存储 ， 供 


Docker Daemon 调用。 


Docker Daemon 执行 CmdPull 任 务 的 pulllmage 阶 段 时 ， 实 现 
Docker 镜 像 存 储 与 记录 的 源码 位 于 ./docker/graph/pull.go#L283- 
L285 , 如下: 


err = s.graph.Register(imgJSON,utils.ProgressReader(layer, imgSize, out, sf, 
false, utils.TruncateID(id), “Downloading”),img) 


以 上 源码 的 实现 ， 实 际 调用 了 函数 Register , Registen 疯 数 的 定 
义 位 于 ./docker/graph/graph.go#L162-L218 , 如 下 : 


func (graph *Graph) Register(jsonData [lbyte, layerData archive.ArchiveReader， 
img *image.Image) (err error) 


分 析 以 上 Registen 溪 数 的 定义 ， 可 以 得 出 以 下 内 容 : 
1) 上 六 数 名 称 为 Register ; 
) 郧 数 调用 者 类 型 为 Graph ; 


3) 传 入 函数 的 参数 有 3 个 : 第 一 个 为 jsonData , 类 型 为 数组 ; 
第 二 个 为 layerData , 类 型 为 archive.ArchiveReader ; 第 三 个 为 


img， 类 型 为 *image.Image ; 
) 邹 数 返回 对 象 为 err， 类 型 为 error。 


Register 数 的 运行 流程 如 图 10-1 所 示 。 


验证 镜像 ID 
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图 10-1 Register 级 数 执行 流程 


10.3 验证 镜像 ID 


Docker 镜 像 注 册 的 第 一 个 步 又 是 验证 Docker 镜 像 的 ID。 此 步骤 
确保 镜像 ID 命名 的 合法 性 。 就 功能 而 言 ， 这 部 分 内 容 提 高 了 Docker 
镜像 存储 环节 的 鲁 棒 性 。 验 证 镜像 ID 由 三 个 环节 组 成 。 

) 验证 镜像 ID 的 合法 性 ; 
2) 验证 镜像 是 否 已 存在 ; 
3) 初始 化 镜像 目录 。 
验证 镜像 ID 的 合法 性 使 用 包 utils 中 的 ValidatelD 纯 数 完成 ， 实 现 
源码 位 于 ./docker/graph/graph.go#L171-L173 , 如 下 : 


if err := utils.ValidateID(img.1ID); err != nil { 


return err 


ValidatelD 罗 数 的 实现 过 程 中 ,， Docker Dameon 检 验 了 镜像 1D 
否 为 空 ， 以 及 镜像 ID 中 是 否 存 在 字符 ″: ”, 以 上 两 种 情况 只 要 其 中 
一 成 立 ,Docker Daemon 就 认为 镜像 ID 不 合法 ， 不 予 执 行 后 续 内 


并 


汗 


了 


镜像 ID 的 合法 性 验证 完毕 之 后 ，Docker Daemon 接 着 验证 镜像 
是 否 已 经 存在 于 Graph 中 。 若 该 镜像 已 经 存在 于 Graph 中 ， 则 
Docker Daemon 返 回 相 应 错误 ， 不 予 执 行 后 续 内 容 。 代 码 实 现 如 
下 : 


if graph.Exists(img.ID) { 
return fmt.Errorf("Image %s already exists", img.ID) 
} 


验证 工作 完成 之 后 ，Docker Daemon 为 镜像 准备 存储 路 径 。 该 
部 分 源码 实现 位 于 ./dockergraph/graph.go##L182-L196 , 如 下 : 


if err := 0S.RemoveALL(graph,ImageRoot(img.ID)); err != nil é&& 
los.IsNotExist(err) { 
return err 


// If the driver has this ID but the graph doesn't, remove it from the driver to 
start fresh. 
// (the graph is the source of truth). 
// Ignore errors, since we don't know if the driver correctly returns 
ErrNotExist. 
// (FIXME: make that mandatory for drivers). 
graph.driver.Remove(img.ID) 
tmp, err := graph.Mktemp("") 
defer os.RemoveAll (tmp) 
if err != nil { 
return fmt.Errorf("Mktemp failed: %s", err) 
} 


Docker Daemon 为 镜像 初始 化 存储 路 径 ， 实 则 首先 删除 属于 新 
镜像 的 存储 路 径 ， 即 如 果 该 镜像 路 径 已 经 在 文件 系统 中 存在 ,立即 删 
除 该 路 径 ， 确 保存 储 镜像 时 不 会 出 现 路 径 冲 突 问 题 ; 接着 还 删除 
graph.driver 中 的 指定 内 容 ， 即 如 果 该 镜像 在 graph.driver 中 存在 ， 
卸载 该 镜像 在 宾主 机 上 的 目录 ， 并 将 该 目录 完全 删除 。 以 AUFS 这 种 


类 型 的 graphdriver 为 例 ， 镜像 内 容 存放 在 /var/lib/docker/aufs/diff 
目录 下 ， 而 镜像 会 被 挂 载 至 目录 /var/lib/docker/aufs/mnt 下 的 指定 
位 置 。 


至 此 ， 验 证 Docker 镜 像 ID 的 工作 已 经 完成 ， 并 且 Docker 
Daemon 已 经 完成 对 镜像 存储 路 径 的 初始 化 ， 使 得 后 续 Docker 镜 像 
存储 时 存储 路 径 不 会 冲突 ，graph.driver 对 该 镜像 的 挂 载 也 不 会 冲 


Pm 


var 
人 人。 


10.4 创建 镜像 路 径 


创建 镜像 路 径 ， 是 镜像 存储 流程 中 的 一 个 必 备 环节 ， 这 一 环节 直 
接 让 Docker 使 用 者 了 解 以 下 概念 : 镜像 以 何 种 形式 存在 于 本 地 文件 系 
统 的 何 处 。 创 建 镜像 路 径 完 毕 之 后 , Docker Daemon 首 先 将 镜像 的 
所 有 祖先 镜像 通过 aufs 文 件 系统 挂 载 至 mnt 下 的 指定 点 ， 最 终 直接 返 
回 镜像 所 在 rootfs 的 路 径 ， 以 便 后 续 直接 在 该 路 径 下 解压 Docker 镜 像 
的 具体 内 容 ( 只 包含 layer 内 容 ) 。 


10.4.1 创建 mnt、diff 和 layers 子 目录 


创建 镜像 路 径 的 源码 实现 位 于 ./docker/graphy/graph.go##L198- 
L206 ,如 下 : 


// Create root filesystem in the driver 
if err := graph.driver.Create(img.ID, img.Parent); err != nil { 
return fmt.Errorf("Driver %s failed to create image rootfs %s: %s", 
graph.driver, img.ID, err) 
} 


// Mount the root filesystem so we can apply the diff/Layer 
rootfs, err := graph.driver.Get(img.ID, "") 
if err != nil { 
return fmt.Errorf("Driver %s failed to get image rootfs %s: %s", 
graph.driver, img.ID, err) 
} 


以 上 源码 中 Create 贞 数 在 创建 镜像 路 径 时 起 到 举足轻重 的 作用 。 
首先 分 析 graph.driver.Create( img.ID ,img.Parentb 的 具体 实 
现 。 由 于 在 Docker Daemon 局 动 时 ， 注册 了 具体 的 graphdriver ， 
故 graph.driver 实 际 的 值 为 具体 注册 的 driver。 方 便 起 见 ， 本 章 内 容 
全 部 以 aufs 类 型 为 例 ， 即 在 graph.driver 为 aufs 的 情况 下 ,阐述 
Docker 镜 像 的 存储 。 在 Ubuntu 14.04 系 统 上 ，Docker Daemon 的 
根 目录 一 般 为 /varlib/docker , 而 aufs 类 型 driver 的 镜像 存储 路 径 一 
般 为 /varlib/dockeraufs。 


aufs 这 种 联合 文件 系统 的 实现 ， 在 合并 多 个 镜像 时 起 到 至 关 重 要 
的 作用 。 首 先 介绍 Docker Daemon 如 何 为 镜像 创建 镜像 路 径 ， 以 便 


支持 通过 aufs 来 union 镜 像 。aufs 模 式 下 ,graph.driverCreate 
( img.ID ,img.Parentb 的 具体 源码 实现 位 
于 ./docker/daemon/graphdriver/aufs/aufs.go#L161-L190 ,如 


下 : 


// Three folders are created for each id 
// mnt, layers, and diff 
func (a *Driver) Create(id, parent string) error { 
if err := a.createDirsFor(id); err != nil { 
return err 


} 
// Write the layers metadata 
f, err := os.Create(path.Join(a.rootPath(), "layers", id)) 
if err != nil { 
return err 


} 
defer f.Close() 


if parent != "" { 
ids, err := getParentIds(a.rootPath(), parent) 
if err != nil 


return err 


} 
if , err := fmt.Fprintln(f, parent); err != nil { 


return err 
for , i := range ids { 
if , err := fmt.Fprintln(f, i); err != nil { 
return err 
} 
} 
return nil 


在 Create 国 数 的 实现 过 程 中 ,createDirsFor 钢 数 在 Docker 
Daemon 根 目录 下 的 aufs 目 录 /varvlib/dockeraufs 中 ， 创 建 指定 的 
镜像 目录 。 若 当前 aufs 目 录 下 还 不 存在 mnt、diff 这 两 个 目录 ， 则 会 首 
先 创建 mnt、diff 这 两 个 目录 ， 并 在 这 两 个 目录 下 分 别 创建 代表 镜像 内 
容 的 文件 夹 ,文件 夹 名 为 镜像 ID ， 文件 权 限 为 0755。 假 设 下 载 镜 像 的 
镜像 ID 为 image_ID， 则 创建 完毕 之 后 ,文件 系统 中 的 文件 


为 /var/lib/dockeraufs/mntimage ID 

与 /varvlib/dockeraufs/diffWimage ID。 回 到 Create 约 数 中 ,执行 
完 createDirsFor 甬 数 之 后 ， 随 即 在 aufs 目 录 下 创建 了 layers 目 录 ， 并 
在 layers 目 录 下 创建 image_ID 文 件 。 


如 此 一 来 ， 在 aufs 下 的 三 个 子 目 录 mnt、diff 以 及 layers 中 ， 分 别 
创建 了 名 为 镜像 名 image_ID 的 文件 。 继 续 深入 分 析 之 前 ， 我 们 直接 来 
看 Docker 对 这 三 个 目录 mnt、diff 以 及 layers 的 描述 ， 如 图 10-2 所 


小。 


10-2 aufs drive 虽 录 结 构图 


简要 分 析 图 10-2， 其 中 ,layers、diff 以 及 mnt 为 目 
录 /Var/lib/docker/aufs 下 的 三 个 子 目录 ，1、2、3 是 镜像 ID ,分 别 代 
表 三 个 镜像 ， 三 个 目录 下 的 1 均 代 表 同 一 个 镜像 ID。 其 中 layers 目 录 下 


保留 每 一 个 镜像 的 元 数据 ， 这 些 元 数据 是 这 个 镜像 的 祖先 镜像 ID 列 
表 ; dif 人 目录 下 存储 每 一 个 镜像 所 在 的 layer , 具体 包含 的 文件 系统 内 
容 ; mn 组 录 下 每 一 个 文件 都 是 一 个 镜像 I/D， 代 表 在 该 层 镜像 之 上 挂 
载 的 可 读 写 layer。 因 此 ， 下 载 的 镜像 中 与 文件 系统 相关 的 具体 内 容 ， 
都 会 存储 在 dif 人 自 录 下 的 示 个 镜像 ID 目录 下 。 


再 次 回 到 Create 函 数 ， 此 时 mnt、diff 以 及 layers 三 个 目录 下 的 
镜像 ID 文件 已 经 创建 完毕 。 下 一 步 需 要 完成 的 是 : 为 layers 目 录 下 的 
镜像 1D 文 件 填充 元 数据 。 元 数据 内 容 为 该 镜像 的 所 有 祖先 镜像 ID 列 
表 。 填 充 元 数据 的 流程 如 下 : 


1) Docker Daemon 首先 通过 f , err : =os.Create( path.join 
( a.rootPath( ) ，"layers" ,id) ) 打开 layers 目 录 下 镜像 1D 文 
件 ; 


2) 然后 ,通过 ids, err : = getParentlds( a.rootPath( ) 
parent) 获取 父 镜像 的 祖先 镜像 ID 列表 ids ; 


3) 其 次 ， 将 父 镜像 ID 与 入 文件 f ; 
) 最 后 ,将 父 镜 像 的 祖先 镜像 ID 列表 ids 与 入 文件 f。 


最 终 的 结果 是 : 该 镜像 的 所 有 祖先 镜像 的 镜像 ID 信息 都 写 入 
layers 目 录 下 该 镜像 ID 文件 中 。 


10.4.2 挂 载 祖先 镜像 并 退回 根 目录 


Create 响 数 执行 完毕 ， 意味 着 创建 镜像 路 径 并 配置 镜像 元 数据 完 
, 接着 Docker Daemon 返 回 镜像 的 根 目录 ， 源 码 实现 如 下 : 


rootfs，err := graph.driver.Get(img.ID, "") 


Get 绚 数 看 似 返回 了 镜像 的 根 目录 rootfs， 实则 执行 了 更 为 重要 的 
内 容 一 一 挂 载 祖先 镜像 文件 系统 。 具 体 而 言 ,Docker Daemon 为 当 
前 层 的 镜像 完成 所 有 祖先 镜像 的 Union Mount。 挂 载 完 毕 之 后 ， 当 前 
镜像 的 read-write 层 位 于 /varlib/dockeraufs/mntimage ID。 
Get 纹 数 的 具体 实现 位 
于 ./docker/daemon/graphdriver/aufs/aufs.go#L247-L278 ,如 


func (a *Driver) Get(id, mountLabel string) (string, error) { 
ids, err := getParentIds(a.rootPath(), id) 
if err != nil { 
If los.IsNotExist(err) { 
return "", err 


} 
ids = []string{} 


} 
// Protect the a.active from concurrent access 


a.Lock() 
defer a.Unlock() 
count := a.active[id] 


// If a dir does not have a parent ( no layers )do not try to mount 
// just return the diff path to the data 
out := path.Join(a.rootpath(), "diff", id) 
if len(ids) > 0 { 
out = path.Join(a.rootPath(), "mnt", id) 
if count == 0 { 
if err := a.mount(id, mountLabel); err != nil { 


return "", err 


} 


} 
a.active[id] = count + 1 
return out, nil 


} 
分 析 以 上 Get 呐 数 的 定义 ， 可 以 得 出 以 下 内 容 : 
1) 肯 数 名 为 Get ; 
2) 归 数 调用 者 类 型 为 Driver ; 
3) 传 入 函数 的 参数 有 两 个 : id 与 mountlabel ; 


4) 函数 返回 内 容 有 两 部 分 : string 类 型 的 镜像 根 目录 与 错误 对 象 


error。 


清楚 Get 纯 数 的 定义 ， 再 来 看 Get 纹 数 的 实现 。 分 析 Get 纹 数 实现 
时 ,有 三 个 部 分 较为 关键 ， 分 别 是 Driver 实 例 a 的 active 属 性 、 
mount 操 作 以 及 返回 值 out。 


首先 分 析 Driver 实 例 a 的 active 属 性 。 分 析 active 属 性 之 前 ， 需 
追溯 至 Jaufs 类 型 的 graphdriver 中 Driver 类 型 的 定义 以 及 
graphdriver 与 Graph 的 关系 。 两 者 的 关系 如 图 10-3 所 示 。 


sync. RWMutex 
trie *patricia. Tree 
ids maplstring|]struct {} 








Root string 
idIndex *truncindex. TruncIndex 


driver graphdriver.Driver Driver(aufs) 


root String 
sync. Mutex 


active map[stringjint 


图 10-3 Graph 与 graphdriver 的 关系 


Driver 类 型 的 定义 位 


于 ./docker/daemon/graphdriver/aufs/aufs#L53-L57 , 如下: 


type Driver struct { 


root string 
sync.Mutex // Protects concurrent modification to active 
active map[string]int 


Driver 结 构 体 中 root 属 性 代表 graphdriver 所 在 的 根 目 录 ， 
即 /var/lib/dockervaufs。active 属 性 为 nap 类 型 ，key 为 string , 具 
体 运用 时 key 为 DockerlImage 的 ID，value 为 int 类 型 ， 代 表 该 层 镜像 
layer 被 引用 的 次 数 总 和 。Docker 镜 像 技 术 中 ， 某 一 个 layer 的 
Docker 镜 像 被 引用 一 次 ， 则 active 属 性 中 key 为 该 镜像 ID 的 value 值 
会 累加 1。 用 户 执行 镜像 删除 操作 时 ，Docker Dameon 会 检查 该 
Docker 镜 像 的 引用 次 数 是 否 为 0， 若 引用 次 数 为 0， 则 可 以 彻底 删除 该 
镜像 ， 若 非 零 ， 则 仪 仅 将 active 属 性 中 引用 参数 减 1]。 属 性 


sync.Mutex 用 于 多 个 job 同时 操作 active 属 性 时 ， 确 保 active 数 据 的 
同步 工作 。 


接着 ， 进 入 挂 载 操 作 的 分 析 。 一 旦 Get 参 数 传 入 的 镜像 1D 人 参数 不 是 
一 个 基础 镜像 ， 那 么 说 明 该 镜像 存在 父 镜 像 ，Docker Daemon 需 要 
将 该 镜像 所 有 的 祖先 镜像 都 挂 载 到 指定 的 位 置 ， 指 定位 置 
为 /var/lib/dockeraufs/mntimage _ ID。 所 有 祖先 镜像 的 原生 态 文 
件 系 统 内 容 分 别 位 于 /var/lib/docker/aufs/diff/<1D> 。 其 中 mount 
纹 数 用 于 实现 该 部 分 描述 的 功能 ， 挂 载 的 过 程 包含 很 多 与 aufs 文 件 系 
统 相 关 的 参数 配置 与 系统 调用 。 


最 后 ，Get 驻 数 返 回 out 与 nil。 其 中 out 的 值 
为 /var/lib/docker/aufs/mnt/image_ID， 即 使 用 该 层 Docker 镜 像 时 
其 根 目录 所 在 路 径 ， 也 可 以 认为 是 镜像 的 RW 层 所 在 路 径 ， 但 一 旦 该 层 
镜像 之 上 还 有 镜像 ， 那 么 在 挂 载 后 者 之 后 ， 在 上 层 镜 像 看 来 ， 下 层 镜 
像 仍然 是 只 读 文 件 系统 。 


10.5 存储 镜像 内 容 


存储 镜像 内 容 ， 意味 着 Docker Daemon 以 及 验证 过 镜像 ID ， 同 
时 还 为 镜像 准备 了 存储 路 径 ， 并 返回 了 其 所 有 祖先 镜像 执行 Union 
Mount 操 作 后 的 路 径 。 万 事 俱 备 ， 只 从 “镜像 内 容 的 存储 ”。 


Docker Daemon 为 了 存储 镜像 具体 内 容 完成 的 工作 很 简单 ， 仅 
仅 是 通过 某 种 合适 的 方式 将 两 部 分 内 容 存 储 于 本 地 文件 系统 并 进行 有 
效 管理 ， 两 部 分 内 容 是 镜像 压缩 内 容 、 镜 像 json 信 息 。 


存储 镜像 内 容 的 源码 实现 位 于 ./docker/graph/graph.go#L209- 
L211 ,如 下 : 


if err := image.StoreImage(img, jsonData, layerData, tmp, rootfs); err != nil { 
return err 


其 中 ,Storelmage 函 数 的 定义 位 
于 ./docker/docker/image/image.go#L74 ,如 下 : 


func StoreImage(img *Image, jsonData []byte, layerData archive.ArchiveReader， 
root, layer string) error 


分 析 Storelmage 函 数 的 定义 ， 可 以 得 出 以 下 信息 : 


1) 上 印 数 名 称 : Storelmage ; 


2) 传 入 顺 数 的 参数 名 : img、jsonData、layerData、root、 


layer ; 
3) 上 遇 数 返回 类 型 error。 
传 入 参数 的 含义 如 表 10-1 所 示 。 


表 10-1 Storelmage 国 数 的 传 入 参数 














img 通过 下 载 的 imgJSON 信息 创建 出 的 Image 对 象 实例 

jsonData Docker Daemon 之 前 下 载 的 imgJSON 信息 

layerData 镜像 作为 一 个 layer 的 压缩 包 ， 包 含 镜像 的 具体 文件 内 容 

root graphdriver 根 目录 下 创建 的 临时 文件 “tmp”， 值 为 /var/lib/docker/aufs/_tmp 
layer 挂 载 完 所 有 祖先 镜像 之 后 ， 该 镜像 在 mnt 目录 下 的 路 径 





掌握 Storelmage 国 数 传 入 参数 的 含义 之 后 ， 理 解 其 实现 就 十 分 简 
单 。 总 体 而 言 ，Storelmage 亦 可 以 分 为 三 个 步骤 : 


1) 解压 镜像 内 容 layerData 至 dif 人 由 录 ; 
2) 收集 镜像 所 占 空间 大 小 ， 并 记录 ; 
3) 将 jsonData 信 息 写 入 临时 文件 。 


下 面 详细 介绍 三 个 步 又 的 实现 。 


10.5.1 解压 镜像 内 容 


Storelmage 国 数 传 入 的 镜像 内 容 是 一 个 压缩 包 ,Docker 
Daemon 理 应 在 镜像 存储 时 将 其 解压 ， 为 后 续 创 建 容 器 时 直接 使 用 镜 
像 创造 便利 。 


既然 是 解压 镜像 内 容 ， 那 么 这 项 任务 的 完成 ， 除 了 需要 代表 镜像 
的 压缩 包 之 后 ， 还 需要 解压 任务 的 目 标 路 径 ， 以 及 解压 时 的 参数 。 压 
缩 包 为 传 入 Storelmage 的 参数 layerData ， 而 目 标 路 径 
为 /var/lib/docker/aufs/diff/<image_ID> 。 解 压 流程 的 源 代 码 位 
于 ./docker/docker/image/image.go#L85-L120 , 如 下 : 


// If layerData is not nil, unpack it into the new layer 
if LayerData != nil { 
if differ, ok := driver. (graphdriver.Differ); ok { 
if err := differ.ApplyDiff(img.ID, layerData); err != nil { 
return err 


if size, err = differ.DiffSize(img.ID); err != nil { 
return err 


} 
} else { 
start := time.Now().UTC() 
log.Debugf ("Start untar layer") 
if err := archive.ApplyLayer(layer, layerData); err != nil { 
return err 


} 
log.Debugf ("Untar time: %vs", time.Now().UTC().Sub(start).Seconds()) 
if img.Parent == "" { 


if size, err = utils.TreeSize(layer); err != nil { 
return err 
} 
} else { 
parent, err := driver.Get(img.Parent, "") 
if err != nil { 
return err 


} 
defer driver.Put(img.Parent) 
changes, err := archive.ChangesDirs(layer, parent) 


if err != nil { 
return err 


} 
size = archive.ChangesSize(layer, changes) 


可 见 , 当 镜 像 内 容 layerData 不 为 空 时 , Docker Daemon 需 
为 镜像 压缩 包 执行 解压 工作 。 以 aufs 这 种 graphdriver 为 例 , 一旦 
aufs driver 实 现 了 graphdriver 包 中 的 接口 Diff, Docker Daemon 
就 会 使 用 aufs driver 的 接口 方法 实现 后 续 的 解压 操作 。 解 压 操作 的 源 
代码 如 下 : 


if differ, ok := driver.(graphdriver.Differ); ok { 
if err := differ.ApplyDiff(img.ID, layerData); err != nil { 


return err 
} 
if size, err = differ.DiffSize(img.1D); err != nil { 
return err 
} 


以 上 代码 实现 了 镜像 压缩 包 的 解压 与 镜像 所 占 空间 大 小 的 统计 。 
代码 differApplyDiff( img.ID ,layerData) 将 layerData 解 压 至 目 
标 路 径 。 理 清 目 标 路 径 ， 且 看 aufs driver 中 ApplyDiff 的 实现 ， 位 
于 ./docker/docker/daemon/graphdriver/aufs/aufs.go#L304- 
L306 , 如下: 


func (a *Driver) AppLyDiff(id string, diff archive.ArchiveReader) error { 
return archive.Untar(diff, path.Join(a.rootPpath(), "diff", id), nil) 
3 


解压 过 程 中 , Docker Daemon 通 过 aufs driver 的 根 目 
录 /var/lib/docker/aufs、dif 租 录 与 镜像 ID， 拼 接 出 镜像 的 解压 路 


径 ， 并 执行 解压 任务 。 


举例 说 明 diff 文 件 的 作用 ， 镜像 27 d47 4 解压 后 


的 内 容 如 图 10-4 所 示 。 


回 到 Storelmage 兄 数 的 执行 流 中 ，ApplyDiff 任 务 完成 之 后 ， 


Docker Daemon 通 过 DiffSize 开 启 镜像 磁盘 空 


间 统 计 任 务 。 


rootewvm:/var/Liby/docker/yaufs/diff/27d47432a69bca5f2700e4dff7de6388ed65f9d3fblec645e2bc24c223dclcc3 洋 让 


total 100 


drwxr-xr-x 21 root root 4096 Feb 1 16:11 ./ 
drwxr-xr-x 165 root root 20480 Mar 29 11:12 . .7 


drwxr-xr-Xx 
drwxr—xr—x 
drwxr-xr-x 
drwxr-xr-X 
drwxr-xr-x 
drwxr-Xr-X 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drwxr-xr-x 
drywxr-xr-X 


drwxr-Xr-X 
drwxr-Xr-X 
drwxr—xr—x 
drwxrF-XF-X 
drwxrwxrwt 
drwxr -Xxr-x 
drwxr-xr-x 


2 root root 
2 root root 
3 root root 
bl1 root root 
2 root root 
12 root root 
2 root root 
2 root root 
Z root root 
2 root root 
2 root root 
2 root root 
7 root root 
2 root root 
2 root root 
2 root root 
2 root root 
10 root root 
11 root root 


4096 Jan 29 00:28 bin/ 
4096 Apr 11 2014 boot/ 
14996 Jan 29 00:28 dev/ 
4096 Jan 29 00:28 etc/ 
4096 Apr 11 2014 home/ 
40996 Jan 29 00:28 lib/ 
4096 Jan 29 00:28 lib64/ 
4096 Jan 29 00:28 media/ 
4096 Apr 11 2014 mnt/ 
4096 Jan 29 00:28 opt/ 
40996 Apr 1i1 2814 proc/ 
4096 Jan 29 00;28 root/ 
4896 Jan 29 00:28 run/ 
40996 Jan 29 00:28 sbin/ 
4096 Jan 29 00:28 srv/ 
4096 Mar 13 2814 sys/ 
4096 Jan 29 90:29 WE/ 
4096 Jan 29 00:28 usr/ 
4096 Jan 29 00:28 var/ 


root@vm: /var/lib/docker/aufs/diff/27d47432a69bca5Sf2700e4dff7de0388ed65f9d3fbliec645e2bc24c223dcicc3 





图 10-4 镜像 解压 后 示意 图 


10.5.2 收集 镜像 大 小 并 记录 


Docker Daemon 接 管 镜像 存储 之 后 ，Docker 镜 像 被 解 讨 到 指 
定 路 径 并 非 意味 着 “任务 完成 "。Docker Daemon 还 统计 了 镜像 所 占 
磁盘 空间 的 大 小 ， 以 便 记 录 镜 像 信 息 ， 最 终 将 这 类 信息 传递 给 Docker 
用 户 。 


镜像 所 占 磁盘 空间 大 小 的 统计 与 记录 ， 实现 过 程 简 单 且 有 效 ， 源 
代码 位 于 ./docker/docker/image/image.go#L122-L125 ,如 下 : 
img.Size = size 


if err := img.SaveSize(root); err != nil { 
return err 


首先 Docker Daemon 将 镜像 大 小 收集 起 来 ， 更 新 Image 类 型 实 
例 img 的 Size 属 性 ， 然 后 通过 img.SaveSize( root) 将 镜像 大 小 与 
入 roo 词 录 ,由 于 传 入 的 root 参 数 为 临时 目录 tmp，, 即 与 入 临时 目录 
_tmp 下 。 实 现 SaveSize 贞 数 的 源码 如 下 : 


func (img *Image) SaveSize(root string) error { 
if err := ioutil.WriteFile(path.Join(root, "layersize"), 
[Jbyte(strconv.Itoa(int(img.Size))), 0600); err != nil { 
return fmt.Errorf("Error storing image size in %s/layersize: %s", 
root, err) 


return nil 


SaveSize 上 加 数 在 roo 让 录 ( 临时 目 
录 /varlib/dockergraph/_ tmp) 下 创建 文件 layersize ,并 写 入 镜 
像 大 小 的 值 img.Size。 


10.5.3 存储 jsonData 信 息 


在 Docker 镜 像 中 , jsonData 是 一 个 非常 重要 的 概念 。 在 笔者 看 
来 ，Docker 的 镜像 并 非 只 是 Docker 容 器 文件 系统 中 的 文件 内 容 ， 同 
时 还 包括 Docker 容 硕 运 行 的 动态 信息 。 这 里 的 动态 信息 更 多 地 是 为 了 
适 配 Dockerfile 的 标准 。 以 Dockerfile 中 的 ENV 参 数 为 例 ，ENV 指 定 
了 Docker 容 器 运行 时 内 部 进程 的 环境 变量 。 而 这 些 只 有 容器 运行 时 才 
存在 的 动态 信息 ， 并 不 会 被 记录 在 静态 的 镜像 文件 系统 中 ， 而 是 以 
jsonData 的 形式 先 存储 在 宿主 机 的 文件 系统 中 ， 并 与 镜像 文件 系统 泾 
渭 分 明 ,存储 在 不 同 的 位 置 。 当 Docker Daemon 局 动 Docker 容 关 
时 ,Docker Daemon 会 准备 好 挂 载 完 毕 的 镜像 文件 系统 环境 ; 接着 
加 载 jsonData 信 息 ， 并 在 运行 Docker 容 器 内 部 进程 时 ， 使 用 动态 的 
jsonData 内 部 信息 为 容器 内 部 进程 配置 环境 。 


当 Docker Daemon 下载 Docker 镜 像 时 ， 关 于 每 一 个 镜像 的 
jsonData 信 息 均 会 被 下 载 至 宿主 机 。 通 过 以 上 jsonData 的 功能 描述 
可 以 发 现 ， 这 部 分 信息 的 存储 同样 扮演 重要 的 角色 。 关 于 Docker 
Daemon 如 何 存储 jsonData 信 息 ， 实现 源码 位 
于 ./docker/docker/image/image.go#L128-L139 , 如 下 : 

if jsonData != nit { 


if err := ioutil.WriteFile(jsonPath(root), jsonData, 0600); err != nil { 
return err 


} 
} else { 


if jsonData, err = json.Marshal(img); err != nil { 
return err 

} 

if err := ioutil.WriteFile(jsonPath(root), jsonData, 0600); err != nil { 
return err 

} 


} 


可 见 Docker Daemon 将 jsonData 写 入 了 文件 jsonPath 
( roob 中 ， 并 且 把 该 文件 的 权限 设置 为 0600。 而 jsonPath 
( roob 的 实现 如 下 , 即 在 roo 诅 录 ( /var/lib/docker/graph/_tmp 
目录 ) 下 创建 文件 json : 


func jsonPath(root String) String { 
return path.Join(root, "json") 


镜像 大 小 信息 layersize 信 息 统计 完毕 ，jsonData 信 息 也 成 功 记 
录 ， 两 者 的 存储 文件 均 位 于 /var/lib/docker/graph/_tmp 下 ,文件 名 
分 别 为 layersize 和 json。 使 用 临时 文件 夹 来 存储 这 部 分 信息 并 非 偶 
然 ，10.6 节 将 阐述 其 中 的 原因 。 


10.6 注册 镜像 ID 


Docker Daemon 执 行 完 镜像 的 Storelmage 操 作 , 回 到 
Registen 疹 数 之 后 ,执行 镜像 的 commit 操 作 ， 即 完成 镜像 在 Graph 
中 的 注册 。 


注册 镜像 的 代码 实现 位 
于 ./docker/docker/graph/graph.go#L212-L216 , 如 下 : 


// commit 
if err := os.Rename(tmp, graph.ImageRoot(img.ID)); err != nil { 
return err 


} 
graph.idIndex.Add(img.ID) 


10.5 节 存储 镜像 过 程 中 使 用 到 的 临时 文件 tmp 在 注册 镜像 环节 
有 所 体现 。 关 于 镜像 的 注册 行为 ， 第 一 步 就 是 将 tmp 文件 
( /var/lib/docker/graph/_tmp) 重 命名 为 graph.ImageRoot 
( img.ID) ， 实则 为 /var/lib/docker/graph/<img.ID> 。 使 得 
Docker Daemon 在 而 后 的 操作 中 可 以 通过 img.ID 
在 /varlib/dockergraph 目 录 下 搜索 到 相应 镜像 的 json 文 件 与 
layersize 文 件 。 


成 功 为 json 文 件 与 layersize 文 件 配置 完 正 确 的 路 径 之 后 ， 
Docker Daemon 执行 的 最 后 一 个 步骤 为 : 添加 镜像 ID 至 


graph.idlndex。 源 代码 实现 是 graph.idlndex.Add( img.ID) ， 
Graph 中 idlndex 类 型 为 *truncindex.Trunclndex , Trunclndex 的 
定义 位 于 ./docker/docker/pkg/truncindex/truncindex.go#L22- 
L28 ,如 下 : 


// TruncIndex allows the retrieval of string identifiers by any of their unique 
prefixes. 
// This is used to retrieve image and container IDs by more convenient shorthand 
prefixes. 
type TruncIndex struct { 

sync.RWMutex 

trie *patricia.Trie 

ids map[string]struct{} 
} 


Docker 用 户 使 用 Docker 镜 像 时 ， 一 般 可 以 通过 指定 镜像 ID 来 定 
位 镜像 ， 如 Docker 官 方 的 mongo : 2.6.1 镜 像 1D 为 
c35c0961174d51035d6e374ed9815398b779296b5fOffceb7 
613c8199383f4b1 ,该 ID 长 度 为 64。 当 Docker 用 户 指定 运行 这 个 
Mongo 镜 像 Repository 中 tag 为 2.6.1 的 镜像 时 ， 完 全 可 以 通过 64 位 
的 镜像 ID 来 指定 ， 如 下 : 


docker run -it c35c0961174d51035d6e374ed9815398b779296b5fgoffceb7613c8199383f4b1 
/bin/bash 


然而 ， 记 录 如 此 长 的 镜像 ID， 对 于 Docker 用 户 来 说 ， 稍 显 不 切 
实际 ,而 Trunclndex 的 概念 则 极 大 地 帮助 Docker 用 户 可 以 通过 简短 
的 ID 定位 到 指定 的 镜像 ， 使 得 Docker 镜 像 的 使 用 变 得 尤为 方便 。 原 
理 是 : Docker 用 户 指定 镜像 ID 的 前 缀 ， 只 要 前 缀 满足 在 全 局 所 有 的 


镜像 1D 中 唯一 ,Docker Daemon 就 可 以 通过 Trunclndex 定 位 到 唯 
一 的 镜像 ID。 而 graph.idlndex.Add( img.ID) 正式 完成 将 img.ID 
添加 并 保存 至 TTunclndex 中 。 


为 了 达到 上 一 条 命令 的 效果 ，Docker 用 户 完全 可 以 使 用 
Trunclndex 的 方式 ,当然 ,前 提 是 c35 这 个 字符 串 作 为 前 缀 全 局 唯 


二 人、 人 
, 命令 如 下 : 
docker run -it c35 /bin/bash 


至 此 ，Docker 镜 像 存储 的 整个 流程 已 经 完成 。 概 括 而 言 , 它 主 要 
包含 验证 镜像 、 存 储 镜 像 、 注 册 镜 像 三 个 步骤 。 


10.7 总结 


Docker 镜 像 的 存储 ， 使 得 Docker Hub 上 的 镜像 能 够 遍布 世界 各 
地 变 为 现实 。Docker 镜 像 在 Docker Registry 中 的 存储 方式 与 本 地 化 
的 存储 方式 并 非 一 致 。Docker Daemon 必 须 针 对 自身 的 
graphdriver 类 型 ， 选 择 适 配 的 存储 方式 ， 实 施 镜像 的 存储 。 本 章 也 
在 不 断 强调 一 个 事实 ， 即 Docker 镜 像 并 非 仅仅 包含 文件 系统 中 的 静态 
文件 , 除 此 之 外 ，, 它 还 包含 镜像 的 json 信 息 ,json 信息 中 有 Docker 
容 希 的 配置 信息 ， 如 暴露 端 月 、 环 境 变 量 等 。 


可 以 说 Docker 容 希 的 运行 严重 依赖 于 Docker 镜 像 ， 因 此 了 解 
Docker 镜 像 的 由 来 就 变 得 尤为 重要 。Docker 镜 像 的 下 载 、Docker 镜 
像 的 打包 以 及 构建 新 的 Docker 镜 像 ， 都 无 法 跳出 镜像 存储 的 范畴 。 
Docker 镜 像 的 存储 知识 ， 也 有 助 于 Docker 其 他 概念 的 理解 ， 如 


docker commit、docker build、docker run 等 。 


第 11 章 docker build 实 现 


11.1 引言 


Docker 镜 像 在 Docker 生 态 轿 中 起 到 的 作用 非 同一 般 。 一 起 来 看 
Docker 的 发 展 ， 我 们 甚至 可 以 如 此 评价 : Docker 正 是 凭借 着 其 灵活 
的 镜像 技术 ， 以 及 革命 性 的 镜像 托管 服务 Docker Hub， 在 云 计 算 时 
代 占 据 了 行业 内 极为 有 利 的 位 置 。 其 自身 的 Dockerfile 技 术 甚至 有 可 
能 取代 传统 软件 发 布 的 模式 ， 成 为 行业 内 更 快捷 、 更 有 效 、 更 易于 部 
署 与 管理 的 软件 发 布 模式 。 


Docker 王 生 之 前 ， 软 件 的 发 布 模式 一 直 以 代码 为 核心 。 软 件 开发 
者 首先 在 开发 环境 中 开发 软件 ， 开 发 到 一 定 阶段 后 ， 开 发 者 提交 代码 
至 托管 平台 ; 软件 测试 者 接着 在 测试 环境 中 部 署 软件 代码 ， 做 相应 的 
测试 工作 并 提交 测试 报告 ; 软件 开发 者 与 测试 者 将 软件 完善 至 一 定 阶 
段 后 交付 ， 交 付 形 式 一 般 例 日 是 代码 。 最 终 交付 的 软件 ， 仍 然 需要 在 
另外 的 环境 中 部 著 ， 因 此 软件 对 部 闭环 境 的 要 求 需要 通过 软件 说 明 书 
的 形式 交付 给 客户 。 然 而 ， 真 实 的 部 闭环 境 并 不 一 定 能 与 软件 有 效 地 
结合 ， 这 也 是 以 代码 为 核心 的 软件 发 布 模式 一 直 以 来 的 痛 点 。 


Docker 诞 生 之 后 ， 软件 发 布 模式 似乎 有 了 新 的 转机 。 软 件 代码 依 
然 是 软件 的 重要 组 成 部 分 ， 然 而 ， 与 以 往 不 同 的 是 ,Docker 生 态 圈 中 
软件 的 发 布 使 得 代码 与 运行 环境 并 不 分 离 ， 而 是 将 软件 运行 环境 也 图 
入 软件 范畴 ， 一 并 交付 给 客户 。 客 户 在 获得 软件 之 后 ， 并 不 需要 额外 
地 配置 环境 ， 而 是 能 够 直接 运行 软件 。 这 种 新 模式 的 诞生 极 大 地 吸引 
了 开发 者 的 眼球 ， 传 统 软件 发 布 浆 端 的 剔除 ， 也 逐渐 使 得 Docker 阵 营 
越 来 越 庞大 。 


软件 发 布 模式 的 革新 ， 并 非 信 手 拓 来 ， 革 新 理念 的 外 表 下 是 前 卫 
的 创新 意识 ， 以 及 创新 意识 下 的 技术 积 泥 。Docker 的 镜像 技术 ,可 以 
说 是 传统 联合 文件 系统 在 云 时 代 迎 来 的 又 一 个 春天 。 在 镜像 技术 之 
上 ,Dockerfile 的 设计 则 可 以 认为 是 Docker 公 司 在 镜像 技术 上 抽象 出 
的 一 个 全 新 软件 标准 。 此 标准 一 出 ， 软 件 开发 者 有 能 力 以 一 个 超 乎 想 
象 的 速度 ,发布 包含 运行 环境 的 软件 ， 并 通过 Docker Hub 的 方式 串 
联 全 世界 。 


第 8 章 、 第 9 章 以 及 第 10 章 分 别 介绍 了 Docker 镜 像 的 原理 、 
Docker 镜 像 的 下 载 以 及 Docker 镜 像 的 存储 。 在 这 些 镜像 技术 的 基础 
之 上 ， 理解 在 Docker 环 境 中 如 何 通 过 Dockerfile 构 建 自己 的 Docker 
镜像 ， 就 显得 意义 重大 。 


本 章 从 Docker 1.2.0 的 源码 出 发 ， 分 析 用 户 通 过 Dockerfile 构 建 
出 一 个 Docker 镜 像 的 来 龙 去 脉 。 


分 析 之 前 ， 我 们 首先 来 简单 了 解 docker build 的 作用 。 简 单 而 
言 ， 用 户 可 以 通过 一 个 自 定 义 的 Dockerfile 文 件 以 及 相关 内 容 ， 从 一 
个 基础 镜像 起 步 ， 对 于 Dockerfile 中 的 每 一 条 命令 ， 都 在 原先 的 镜像 
layer 之 上 再 额外 构建 一 个 新 的 镜像 layer , 直至 构建 出 用 户 所 需 的 镜 
像 。 


由 于 docker build 命 令 由 Docker 用 户 发 起 ， 故 docker build 的 
流程 会 员 穿 Docker Client、Docker Server 以 及 Docker Daemon 
这 三 个 重要 的 Docker 模 块 。 本 章 也 正 是 以 这 三 个 Docker 模 块 为 主 
题 ， 分析 docker build 命 令 的 执行 ， 其 中 Docker Daemon 作 为 
Docker 的 重 中 之 重 ， 本 章 对 其 的 分 析 也 将 会 更 加 详细 。 具 体 而 言 , 本 
章 内 容 包 含 以 下 3 部 分 : 


1) 概述 docker build 命 令 执行 的 流程 ， 包含 Docker Client、 


Docker Server 以 及 Docker Daemon ; 
2) 详细 分 析 Docker Daemon 对 Dockerfile 的 build 实 现 ; 


3) 简要 分 析 Dockerfile 中 的 命令 在 Docker Daemon 中 的 执行 


流程 。 


11.2 docker build 执 行 流程 


docker build 可 以 帮助 Docker 用 户 通过 Dockerfile 的 形式 构建 出 
自己 的 Docker 镜 像 。 更 为 细致 的 描述 是 : 用 户 通过 Docker Client 向 
Docker Server 发 送 一 条 docker build 命 令 ， 发 送 命 令 时 ， 用户 需要 
首先 指定 Dockerfile 以 及 相关 内 容 ， 并 通过 Docker Client 将 请 求 发 
出 ; Docker Server 接 收 请 求 之 后 ， 将 其 路 由 转发 至 相应 的 处 理 方 
法 ; Docker Daemon 负 责 执行 请 求 处 理 的 处 理 方法 ， 解 析 
Dockerfile 并 构建 出 最 终 的 镜像 。 


Docker Client、Docker Server 以 及 Docker Daemon 协 同 完成 
build 任 务 的 流程 图 如 图 11-1 所 示 。 


下 面 几 节 将 从 Docker Client、Docker Server 以 及 Docker 
Daemon 三 个 方面 分 析 docker build 的 流程 。 


Docker Server 








Docker Client 解析 请 求 参 数 


创建 并 触发 huild 任 务 


Docker Daemon 


解析 任务 参数 


创建 buildFile 对 象 
执行 build 任 务 


图 11-1 docker build 的 流程 图 


11.2.1 Docker Client 与 docker build 


Docker Client 作 为 用 户 请 求 的 入 口 ， 自 然 第 一 个 接收 并 处 理 
docker build 命 令 。 图 11-1 中 也 已 经 清楚 地 标明 Docker Client 的 处 理 
流程 。 本 章 基 于 Docker 1.2.0 版 本 进行 分 析 ， 随 着 Docker 版 本 的 不 断 
更 新 ，Docker 在 build 的 实现 上 也 有 了 较为 明显 的 更 新 ， 然 而 ， 万 变 不 
离 其 宗 ，docker build 的 思想 与 精 散 并 未 产生 本 质 的 变化 。Docker 
Client 处 理 docker build 命 令 的 流程 图 如 图 11-2 所 示 。 


tag( 镜 像 tag) 
quiet (取消 日 志 输 出 ) 
定义 flag 参 数 no-cache( 使 用 build cache) 
=-rm( 删 除 中 间 容 崔 ) 
forcerm 【强制 副 除 中 间 容 顺 ) 





解析 命令 flag 参 数 


git 或 者 url 
Dockerfile 的 context 
t (镜像 tag) 


q( 取 消 日 志 输 出 ) 
构建 REST 请 求 参数 Url. Values nocache (使 用 build cache) 


rm( 贡 除 中 间 容 器 ) 


forcerm【〔 强制 删除 中 间 容 带 ) 
headers 





SN X-RegiSstry-Config 


发 送 POST 请 求 





Content-Type 


图 11-2 Docker Client 处 理 docker build 命 令 的 流程 图 


关于 Docker Client 端 的 处 理 ,下面 将 从 4 个 方面 分 析 docker 
build 命 令 的 处 理 流 程 。 关 于 Docker 架 构 中 Docker Client 的 构建 与 命 
令 执 行 ， 可 以 参考 第 2 章 。 


1. 定 义 并 解析 flag 参 数 


用 户 发 起 的 Docker 命 令 中 ， 很 多 情况 下 都 会 带 flag 参 数 。 一 般 情 
况 下 ,Docker Client 会 通过 定义 与 解析 ， 对 这 些 flag 参 数 进行 转 义 ， 
从 而 将 用 户 的 请 求 按 需 转换 ， 使 其 适应 于 Docker Server 暴 圳 的 API 接 
口 。 


命令 docker build 的 flag 参 数 共 有 5 个 ， 分别 为 tag、 
suppressOutput、noCache、rm 与 forceRm。flag 参 数 的 源码 定义 
位 于 ./docker/docker/api/client/command.go#L102-L106 ,如 
下 : 


tag := cmd.String([]string{"t", "-tag"}, "", "Repository name (and optionally a 
tag) to be applied to the resulting image in case of success") 

suppressOutput := cmd.Bool([]string{"q", "-quiet"}, false, "Suppress the verbose 
output generated by the containers") 

noCache := cmd.Bool([]string{"#no-cache", "-no-cache"}, false, "Do not use cache 
when building the image") 

rm := cmd.Bool([]string{"#rm", "-rm"}, true, "Remove intermediate containers after 
a successful build") 

forceRm := cmd.Bool([]string{"-force-rm"}, false, "Always remove intermediate 


containers, even after unsuccessful builds") 


5 个 flag 参 数 的 具体 说 明 参 见 表 11-1。 


表 11-1 docker build 命 令 的 flag 参 数 说 明 

















fiag 参数 flag 参数 形式 | fag 参数 默认 值 flag 参数 撒 述 
tag t、-tag ""( 空 字符 串 ) build 完毕 后 为 新 镜像 设置 的 tag 信息 
suppressOutput q、-dquiet false 是 否 输出 容器 产生 的 日 志 等 信息 
noCache -no-cache false 构建 镜像 时 不 使 用 镜像 缓存 
rm -rm true 成 功 构建 镜像 之 后 ,删除 中 间 容 器 
forceRm -force-rm false 强制 删除 中 间 容 器 











需要 强调 的 是 : 在 实际 应 用 场景 中 ，noCache 参 数 的 作用 非常 神 
奇 。 一 旦 -no-cache 参 数 为 false， 则 说 明 不 使 用 镜像 缓存 的 定论 不 成 
立 ， 也 就 是 说 ， 使 用 镜像 缓存 。 命 令 docker build 命 令 执行 时 ， 镜 像 组 
存 会 大 大 缩短 相似 Dockerfile 的 build 时 间 。 比 如 : Dockerfile1 中 第 4 
条 命令 为 编译 、 安 装 某 一 款 软件 ， 执 行 该 命令 本 身 需 要 占用 的 时 间 极 
长 ; 若 Dockerfile2 中 的 前 4 条 命令 与 Dockerfile1 完 全 一 致 ， 并 且 不 涉 
及 内 容 复 制 ， 则 Dockerfile2 在 构建 前 4 条 命令 时 ， 完 全 可 以 使 用 
Dockerfile1 构 建 时 的 镜像 缓存 ， 从 而 大 大 压缩 了 本 次 docker build 所 
消耗 的 时 间 。 


定义 flag 参 数 完毕 之 后 ，Docker Client 随 即 解析 命令 中 的 flag 参 
数 ， 并 对 处 理 结果 进行 处 理 ， 源 码 实 现 如 下 : 


if err := cmd.Parse(args); err != nil { 
return nil 


if cmd.NArg() != 1 { 
cmd.Usage() 
return nil 


} 


至 此 ， 第 一 个 步骤 已 经 完成 ,flag 参 数 解 析 之 后 ， Docker Client 
将 立即 进入 Dockerfile 内 容 采 集 阶段 。 


2. 获 取 Dockerfile 相 关内 容 


命令 docker build 的 初衷 是 为 Docker 用 户 构建 预期 的 镜像 。 为 了 
达到 这 个 目的 ，Docker 用 户 自然 需要 向 Docker Daemon 提 供 必 需 的 
原材料 。 而 这 些 原 材料 正 是 Dockerfile 以 及 其 相关 内 容 。 既 然 如 此 ， 
Docker Client 则 必须 代表 Docker 用 户 提供 这 些 原 材料 。 


Docker Client 在 flag 参 数 解析 完成 之 后 ， 下 一 步骤 即 为 获取 
Dockerfile 相 关内 容 。 最 为 常见 的 Dockerfile 一 般 为 一 个 文件 ， 存在 于 
Docker Client 所 在 的 文件 系统 中 ， 并 且 伴 随 着 一 些 其 他 文件 ， 一 般 是 
Dockerfile 所 在 目录 下 的 其 他 相关 文件 内 容 。 用 户 往往 可 以 在 
Dockerfile 所 在 目录 下 执行 docker build 命 令 来 完成 镜像 构建 。 这 是 
Docker 最 为 普遍 的 构建 方式 ， 分 析 build 的 源码 实现 ， 大 家 就 可 以 发 
现 : Docker 的 build 命 令 支持 的 Dockerfile 源 比 指定 目录 要 丰富 得 多 。 
除 此 之 外 ，Docker 还 支持 从 STDIN 读 取 Dockerfile、 从 远程 URL 获 取 
Dockerfile ,以 及 从 git 源 获取 Dockerfile。 如 何 解 析 Dockerfile 源 并 
且 构 建 context 信 息 的 流程 图 如 图 11-3 所 示 。 










U 





JRL? && (lgit || no git ) 





isRemote=true 
context <— STDIN 


context <~ archive 


图 11-3 解析 Dockerfile 源 并 构建 context 信 息 的 流程 图 


Docker Client 解 析 Dockerfile 源 的 源码 位 
于 ./docker/docker/api/client/command.go#L123-L193 ,如 下 : 





if cmd.Arg(0) == "-" { 
if !archive.IsArchive(magic) { 
dockerfile, err := ioutil.ReadAll (buf) 
if err != nil { 
return fmt.Errorf("failed to read Dockerfile from STDIN: %v", err) 


context, err = archive.Generate("Dockerfile", string(dockerfile)) 
} else { 
context = ioutil.NopCloser(buf) 
} 
} else if utils.IsURL(cmd.Arg(0)) && (!utils.IsGIT(cmd.Arg(0)) || !hasGit) { 
isRemote = true 
} else { 


root := cmd.Arg(0) 
if utils.IsGIT(root) { 


if output, err := exec.Command("git", "clone", "--recursive", 


remoteURL, root).CombinedOutput(); err != nil { 
return fmt.Errorf("Error trying to use git: %s (%s)", err, output) 
} 


options := &archive.TarOptionst{ 
Compression: archive.Uncompressed, 
Excludes: excludes, 


context, err = archive.TarWithOptions(root, options) 
if err != nil { 
return err 


简要 分 析 该 流程 。Docker Client 解 析 完 flag 参 数 之 后 ， 通 过 第 一 
个 参数 cmd.Arg( 0) 来 确定 Dockerfile 源 。 流 程 大 致 如 下 : 


1) 若 该 参数 为 "-"， 则 代表 Docker 用 户 指定 STDIN 作 为 
Dockerfile 的 输入 源 ,Docker Client 随 即 通 过 docker build 命 令 的 标 
准 输入 读 入 数据 ,压缩 后 最 终 得 到 结果 Context ; 


2) 和 若 该 参数 与 URL 匹 配 ， 并 且 不 为 git 地 址 ， 又 或 者 参数 与 URLZ 
配 ， 同 时 也 是 git 地 址 ,但 是 Docker Client 所 在 簿 主机 没有 安装 git ， 
则 标记 isRemote 参 数 为 true ， 表明 Dockerfile 需 要 远程 获取 。 


) 若 该 参数 为 git 地 址 ， 且 本 地 安装 git , 则 Docker Client 首 先 将 
git 内 容 通 过 git clone 命 令 复 制 到 本 地 ; 否则 ,表明 Dockerfile 已 经 位 
于 当前 目录 ，Docker Client 解 析 当 前 路 径 之 后 ,将 内 容 压缩 打包 ,得 
到 最 终结 果 context。 


Docker Daemon 执 行 docker build 命 令 的 原材料 已 经 辨析 清楚 
准备 完毕 。 此 时 ，Docker Client 需 要 为 发 送 请 求 给 Docker Daemon 


做 准备 。 
3. 构 建 REST 请 求 参 数 


构建 REST 请 求 ， 标 志 着 Docker Client 与 Docker Daemon 建 立 
通信 的 开始 。Docker Client 需 要 为 该 请 求 配置 相应 的 参数 ， 比 如 请 求 
体 ， 请 求 url 中 的 参数 值 ， 以 及 请 求 header 等 。 


请 求 体 参 数 的 配置 ， 源 码 位 
于 ./docker/docker/api/dcli/Jcommand.go#L194-L200 , 如下: 
var body io.Reader 


// Setup an upload progress bar 
// FIXME: ProgressReader shouldn't be this annoying to use 


if context != nil { 
sf := utils.NewStreamFormatter(false) 
body = utils.ProgressReader(context, 0, cli.err, sf, true, "", "Sending 


build context to Docker daemon") 


简单 而 言 ,请求 体 的 配置 依赖 context 的 内 容 , 即 Dockerfile 以 及 
相关 内 容 将 作为 请 求 的 body。 


请 求 url 的 参数 配置 其 随 其 后 ， 这 些 url 参 数 有 tag、quiet、 
remote、nocache、rm 与 forcerm。 除 了 remote 参 数 的 值 来 源 于 
cmd.Arg( 0) 之 外 ， 其 他 参数 均 来 源 于 docker build 命 令 的 flag 参 
数 。 


请 求 参数 配置 的 最 后 阶段 是 请 求 header。 由 于 docker build 请 求 
同样 有 可 能 需要 用 户 的 认证 信息 , 故 Docker Client 为 请 求 添 加 了 名 为 
X-Registry-Config 的 header , 值 为 用 户 的 Config 信 息 。 同 时 也 会 由 
于 请 求 body 的 类 型 ， 而 设置 header 中 的 Content-Type 参 数 。 


4. 发 送 POST 请 求 


Docker Client 万 事 准 备 就 绪 之 后 ， 最 后 一 个 步骤 即 发 送 POST 请 
求 至 Docker Server , 由 Docker Server 将 请 求 路 由 至 Docker 
Daemon 中 具体 的 处 理 方法 。 


发 送 请 求 的 源码 位 
于 ./docker/docker/api/dlij/command.go#L245 , 如 下 : 


err = cli,.stream("POST", fmt.Sprintf("/build?%s", Vv.Encode()), body, cli.out, 
headers) 


请 求 类 型 为 POST ， 请求 的 URL 为 /build， 并 携带 url 的 查询 参数 
值 ， 请 求 体 为 body， 请求 也 市 有 header 信 息 。 


当 POST 请 求 发 送 完毕 之 后 ,docker build 在 Docker Client 的 处 
理 就 基本 完成 了 ， 接着 由 Docker Server 以 及 Docker Daemon 扮演 处 
理 请 求 的 角色 。 


11.2.2 Docker Server 与 docker build 


正如 Docker Server 一 如 既往 的 角色 ，, 它 负 责 根据 请 求 类 型 以 及 
请 求 的 URL , 路 由 转发 Docker 请 求 至 相应 的 处 理 方法 。 在 处 理 方法 
中 ，Docker Server 会 创建 相应 的 job， 为 job 配置 相应 的 执行 参数 并 
触发 该 job 的 运行 。 

命令 docker build 在 Docker Client 中 最 终 通过 一 个 POST 请 求 发 
出 ，URL 前 缀 为 build。 而 Docker Server 的 路 由 表 中 有 以 下 这 条 规 
则 , 位于./docker/docker/api/server/server/go#L1123 , 如 下 : 


"POST": { 
" /build": postBuild, 


因此 对 于 docker build 请 求 ，Docker Server 执 行 的 处 理 方法 为 
postBuild。postBuild 的 定义 与 实现 位 
于 ./docker/docker/api/server/server.go#L913 , 如 下 : 


func postBuild(eng *engine.Engine, version version.Version, w http. 
ResponseWriter, r *http.Request, vars map[string]string) error 


此 处 理 方法 的 职责 与 其 他 处 理 方法 无 异 : 解析 请 求 参数 ， 创 建 并 
触发 执行 Jjob。 创 建 的 Job 名 为 build， 代 码 如 下 : 


job = eng.Job("build") 


而 Docker Client 传 递 至 Docker Server 的 url 参 数 ， 均 会 按 规则 
对 job 的 环境 变量 赋值 。 需 要 特殊 说 明 的 是 : 关于 POST 请 求 的 
body , 也 就 是 Dockerfile 相 关内 容 ， 会 以 ob 自身 标准 输入 的 形式 添 
加 至 job 内 部 ， 代 码 如 下 : 


job.Stdin.Add(r.Body ) 


所 有 环境 变量 配置 完毕 之 后 ,Docker Server 执 行 job.Run， 触 
发 执行 这 个 名 为 build 的 Job。 


11.2.3 Docker Daemon 与 docker build 


Docker Daemon 作 为 Docker 体 系 中 的 “大 脑 " 部 分 ,任务 真正 的 
执行 都 由 它 来 完成 ， 请 求 docker build 也 不 例外 。 处 理 docker build 
请 求 ， 意味 着 Docker Daemon 会 接管 build 这 个 Job 的 执行 权 ， 并 将 
任务 完成 。 


Docker Daemon 开 始 执行 的 任务 无 外 乎 也 是 解析 job 环境 变量 ， 
获取 Dockerfile 内 容 。 解 析 job 环 境 变 量 的 源码 位 
于 ./docker/docker/daemon/build.go#L40-L53 , 如 下 : 


var ( 


remoteURL = job.Getenv("remote") 
repoName = job.Getenv("t") 
suppressOutput = job.GetenvBool("q") 
noCache = job.GetenvBool ("nocache") 
rm = job.GetenvBool ("rm") 
forceRm = job.GetenvBool ("forcerm") 
authConfig = &registry.AuthConfig{} 
configFile = &registry.ConfigFile{} 
tag string 

context io.ReadCloser 


) 
job.GetenvjJson("authConfig", authConfig) 
job.GetenvjJson("configFile", configFile) 


Dockerfile 内 容 的 获取 紧 随 其 后 。Dockerfile 及 其 相关 内 容 可 以 
通过 三 种 源 向 Docker Daemon 交 付 ， 因 此, Docker Daemon 获 取 
相关 内 容 时 ,也 需要 首先 通过 参数 分 辩 是 哪 种 具体 方式 ， 并 实现 内 容 


的 最 终 提 取 。Docker Daemon 获 取 Dockerfile 相 关内 容 context 的 沪 
程 图 如 图 11-4 所 示 。 


N context <— Stdin 


N context <~ git clone 


y 






TISURL (remoteURL) ? 





pe 


context <— Download (remoteURL) 





图 11-4 ”Docker Daemon 获取 context 的 流程 图 


这 部 分 的 源码 实现 简单 明了 ， 位 
于 ./dockervdockerdaemon/build.go#L56-L92 , 如下: 


If remoteURL == "" { 
context = ioutil.NopCloser(job.Stdin) 
} else if utils.IsGIT(remoteURL) { 
if !strings.HasPrefix(remoteURL, "git://") { 
remoteURL = "https://" + remoteURL 


} 
root, err := ioutil.TempDir("", "docker-build-git") 
if err != nil { 


return job.Error(err) 


} 
defer os.RemoveAll (root) 
if output, err := exec.Command("git", "clone", "--recursive", remoteURL., 
root).CombinedOutput(); err != nil { 
return job.Errorf("Error trying to use git: %s (%s)", err, output) 


} 
c, err := archive.Tar(root, archive.Uncompressed) 
if err != nil { 
return job.Error(err) 
} 


context = c 
} else if utils.IsURL(remoteURL) { 
f, err := utils .Download (remoteURL) 
if err != nil { 
return job.Error(err) 


} 
defer f.Body.Close() 
dockerFile, err := ioutil.ReadAll (f.Body) 
if err != nil { 
return job.Error(err) 


} 
c, err := archive.Generate("Dockerfile", string(dockerFile)) 
if err != nil { 


return job.Error(err) 


context = c 


分 析 以 上 源码 ,我们 可 以 发 现 Docker Daemon 以 下 的 处 理 逻 
辑 。 若 context 成 功 获取 ， 则 说 明 构 建 Docker 镜 像 的 原材料 已 经 准备 
完毕 ,Docker Daemon 接 着 将 逐一 分 析 context 中 Dockerfile 的 内 
容 ， 并 完成 相应 的 build 语 句 。 虽 然 构 建 Docker 镜 像 的 原材料 已 经 完 
备 ， 但 是 由 Docker Daemon 的 哪个 部 件 来 完成 这 项 重大 的 工作 ， 仍 
然 未 给 出 答案 。 紧 接着 ,Docker Daemon 根 据 context 获 取 的 源 代 
码 ， 创 建 一 个 buildFile 对 象 。 命 令 docker build 的 生命 周期 中 ， 
buildFile 起 到 的 作用 非 同 小 可 。Dockerfile 中 书写 的 所 有 命令 均 由 
buildFile 来 完成 相应 的 build 操 作 。 


首先 ， 我 们 进入 buildFile 结 构 体 的 定义 : 


type buildFile struct { 


daemon *Daemon 


eng *engine.Engine 

image string 

maintainer string 

config *runconfig.Config 
contextPath string 

context *tarsum.TarSum 
verbose bool 
utilizeCache bool 

rm bool 

forceRm bool 


authConfig *registry.AuthConfig 

configFile *registry.ConfigFile 

tmpContainers map[string]struct{} 

tmpImages map[lstring]struct{} 

outStream io.Writer 

errStream io.Writer 

// Deprecated, original writer used for ImagePull. To be removed. 
outOld io.Writer 

sf *utils.StreamFormatter 

// cmdSet indicates is CMD was set in current Dockerfile 
cmdSet bool 





对 于 buildFile 结 构 体 ， 部 分 属性 的 含义 如 表 11-2 所 示 。 


表 11-2 ”buildFile 属 性 说 明 









































属性 名 称 含 》 属性 名 称 含义 
daemon Job 所 属 Daemon forceRm 强制 删除 中 间 容 器 
engine Job 所 属 Engine authConfig 认证 信息 
image 基础 镜像 configFile 配置 文件 
maintainer Dockerfile 维护 者 tmpContainer 临时 容器 列表 
config 运行 配置 参数 tmpImages 临时 镜像 列表 
contextPath context 所 在 路 径 outStream 输出 流 
context context 内 容 errStream 错误 流 
verbose 输出 build outOld Job 的 标准 输出 
utilizeCache 使 用 镜像 缓存 sf StreamFormatter 
rm 删除 中 间 容 器 cmdSet 是 否 指 定 cmd 








其 中 ， buildFile 可 以 认为 是 一 个 生产 镜 亮 像 车 间 , 只 要 有 原材料 
它 就 可 以 按照 要 求 为 用 户 生 产 Docker 镜 像 。 
Docker 构 建 并 初始 化 buildFile 对 象 之 后 ， 随 后 即 开 始 真正 的 build 之 


( Dockerfile) 输入 ， 


旅 ， 车 间 开 始 运作 ， 按 要 求 构 建 镜像 。 镜 像 一 旦 构建 成 功 ，Docker 
Daemon 将 镜像 ID 在 Repository 中 注册 ， 以 便 后 续 使 用 。 这 部 分 的 源 
码 位 于 ./docker/docker/daemon/build.go#L106-L112 , 如 下 : 


id, err := b.Build(context) 
if err != nil 

return job.Error(err) 
} 


if repoName != "" { 
daemon.Repositories().Set(repoName, tag, id, false) 
} 


构建 与 注册 两 项 工作 的 完成 ， 代表 Docker Daemon 的 build 任 务 
大 功 告 成 。Docker Daemon 响应 Docker Server， 并 返回 请 求 响应 
至 Docker Client ,通知 用 户 镜像 构建 任务 的 完成 情况 。 


Docker Client、Docker Server 以 及 Docker Daemon 三 者 协同 
完成 命令 docker build 的 流程 已 经 分 析 完 毕 。 目 前 ,我们 清晰 的 是 流 
程 ， 模 糊 的 是 具体 的 build 执 行 。11.3 克 将 给 出 代码 b.Build 
( context) ， 分 析 Dockerfile 中 具体 命令 的 执行 细节 。 


11.3 ”Dockerfile 命 令 解 析 流 程 


Docker Server 交 付 给 Docker Daemon 的 内 容 是 一 系列 参数 ， 
以 及 Dockerfile 相 关内 容 压缩 后 的 context 对 象 ， 我 们 习惯 于 将 后 者 
称 为 原材料 。Dockerfile 命 令 解 析 也 是 从 原材料 入 手 ， 以 下 是 build 锁 
数 的 执行 流程 ， 如 图 11-5 所 示 。 


1. 创建 临时 文件 


2. 解压 context 


3. 谈 取 Dockerfile 


4. 逐 行 解析 Dockerfile 


5. 成 功 生 成 镜像 





11-5 build 函数 执行 流程 图 


水 数 build 的 执行 过 程 中 ， 第 1~ 3 步 ， 以 及 第 5 步 的 执行 内 容 及 意 
义 简 单 而 清晰 ， 本 节 主 要 分 析 第 4 步 一 一 逐 行 解析 Dockerfile。 逐 行 
解析 Dockerfile 命 令 的 代码 位 
于 ./docker/docker/daemon/build.go#898-L912 , 如下: 


for , line := range strings.Split(dockerfile, "\n") { 
line = strings.Trim(strings.Replace(line, "\t", "~", -1), " \t\r\n") 
if len(line) == 0 { 
continue 
} 
if err := b.BuildStep(fmt.Sprintf("%d", stepN), line); err != nil { 
if b.forceRm { 
b.clearTmp(b.tmpContainers) 
return "", err 
} else if b.rm { 
b.clearTmp(b.tmpContainers) 


} 
stepN += 1 


以 上 代码 的 for 循 环 中 ,每 一 个 循环 均 会 传 入 Dockerfile 中 的 一 
村, 代码 中 变量 为 line。 预 处 理 line 之 后 ,每 次 循环 执行 的 任务 是 
b.BuildStep( ) 级 数 ,并 在 每 一 个 循环 的 最 后 ， 对 循环 次 数 进行 统 
计 。BuildStep 锁 数 的 作用 是 从 line 中 解析 相应 的 Dockerfile 指 令 ， 
完成 构建 一 个 镜像 layer 的 任务 ， 并 在 当前 上 下 文中 执行 。BuildStep 
级 数 的 定义 位 于 ./dockerdockerdaemon/build.go##L921- 
L943 , 如 下 : 


func (b *buildFile) BuildStep(name, expression string) error { 
fmt.Fprintf(b.outStream, "Step %s : %s\n", name, expression) 
tmp := strings.SplitN(expression, " " ) 
if len(tmp) != 2 { 
return fmt.Errorf("Invalid Dockerfile format") 


instruction := strings.ToLower(strings.Trim(tmp[0], " ")) 


arguments := strings.Trim(tmp[1], " ") 
method, exists := reflect.TypeO0f(b).MethodByName("Cmd" + strings. 
ToUpper(instruction[:1]) + strings.ToLower(instruction[1:])) 
if !exists { 
fmt.Fprintf(b.errStream, "# Skipping unknown instruction %s\n", 
strings.ToUpper(instruction)) 
return nil 


ret := method.Func.Call([]reflect.Value{reflect.Value0Of(b), reflect., 
Value0f (arguments)})[0].Interface() 
if ret != nil { 
return ret. (error) 


} 
fmt.Fprintf(b.outStream, " ---> %s\n", utils.TruncateID(b.image)) 
return nil 


自行 编写 过 Dockerfile 的 Docker 爱 好 者 对 于 内 部 每 一 行 的 书写 肯 
定 非 常 清楚 。Dockerfile 的 每 一 行 都 必须 由 命令 类 型 和 命令 参数 两 部 


分 构成 ,如 : 


FROM ubuntu:14.04 

MAINTAINER Allen Sun allen.sun@daocloud.io 
RUN apt-get update 

CMD [“/bin/bash"”] 


因此 ,BuildStep 首 先 通过 一 行 中 第 一 个 空格 字符 "将 传 入 内 容 
分 离 ,如 下 : 


tmp := strings.SplitN(expression, " ", 2) 
instruction := strings.ToLower(strings.Trim(tmp[0], " ")) 
arguments := strings.Trim(tmp[1], " ") 


数组 中 ，tmp[0] 代 表 Dockerfile 中 相应 行 的 命令 类 型 ，tmp[1] 
代表 命令 参数 。 两 者 解析 完毕 后 ， 分别 赋值 给 instruction 与 
arguments。 命 令 类 型 获取 之 后 ，Docker Daemon 巧 妙 地 使 用 了 


Golang 中 的 反射 ( reflect) 机 制 获 取 具 体 的 执行 方法 。 执 行 方法 提 


取 后 ,执行 时 传 入 命令 参数 ， 即 完成 了 一 条 Dockerfile 指 令 的 执行 ， 
代码 如 下 : 


method, exists := reflect.TypeO0f(b).MethodByName("Cmd" + strings. 
ToUpper(instruction[:1]) + strings.ToLower(instruction[1:])) 

ret := method.Func.Call([]l]reflect.Value{reflect.Value0f(b), reflect., 
Value0f (arguments)})[0].Interface() 


对 于 Dockerfile 内 的 每 一 条 命令 ，Docker Daemon 都 会 执行 一 
次 循环 并 通过 反射 完成 方法 的 执行 。 如 Dockerfile 中 的 命令 FROM 
ubuntu : 14.04 , 首先 可 以 解析 出 命令 类 型 为 FROM ， 命令 参数 为 
ubuntu : 14.04 , 即 instruction 值 为 fom , arguments 为 
ubuntu : 14.04 ; 接着 反射 机 制 将 通过 字符 串 “CmdFrom ”找到 方法 
cmdFrom , 即 method 为 CmdFrom ; 最 后 通过 method.Func.Call 
( ) 函数 传 入 参数 ， 完 成 命令 的 执行 。 


11.4 节 将 分 析 Dockerfile 内 具体 命令 的 执行 。 


11.4 Dockerfile 命 令 分 析 


众所周知 ,Docker Daemon 在 构建 Dockerfile 的 过 程 中 ， 对 
Dockerfile 中 的 每 一 条 命令 ( FROM 命令 除外 ) 都 会 构建 一 个 新 的 
image。 因 此 , 围绕 Docker 的 镜像 技术 ，build 的 流程 也 是 创建 一 个 


个 image 的 过 程 。 


对 于 一 个 Dockerfile ， 或 者 Dockerfile 内 的 一 条 或 多 条 命令 ， 
buildFile 对 象 均 完美 地 记录 所 有 命令 执行 时 的 上 下 文 现状 。 


Dockerfile 内 部 的 命令 简单 ， 可 以 分 为 两 类 。 第 一 类 命令 修改 上 
一 层 image 的 文件 系统 内 容 ， 比 如 : 命令 RUN 在 基于 上 一 层 image 的 
容 希 中 运行 一 条 指令 ， 对 于 用 户 而 言 ， 该 指令 很 有 可 能 修改 上 一 层 
image 的 内 容 ; 命令 ADD 在 Dockerfile 所 在 目录 的 context 中 复制 内 
容 至 上 一 层 image， 用户 视 角 下 同样 属于 修改 镜像 ; 这 样 的 命令 还 有 
COPY 等 。 第 二 类 命令 仅仅 修改 镜像 的 config 信 息 ， 比 如 : 命令 ENV 
不 会 修改 镜像 文件 系统 中 的 内 容 ， 而 仅仅 修改 镜像 的 config 的 ENV 信 
息 ， 以 便 后 续 使 用 该 镜像 启动 进程 时 ，ENV 信 息 作 为 进程 的 环境 变量 
加 载 ; 同样 EXPOSE 命 令 代表 以 该 镜像 运行 容 兹 时 ， 容 右 内 进程 会 监 
听 EXPOSE 的 端口 号 ， 以便 Docker Daemon 捕 获 容器 内 的 端口 监听 
情况 ， 这 部 分 信息 同样 会 被 记录 至 config 信 息 ,最 后 被 更 新 至 镜像 的 


json 文 件 中 ; 第 二 类 命令 还 包括 很 多 ， 如 CMD、ENTRYPOINT、 
MAINTAINER 等 。 


本 节 着 重 分 析 三 种 具有 代表 性 的 Dockerfile 命 令 FROM、RUN、 
ENV , 阐述 这 些 命令 解析 执行 时 ,构建 Docker 新 镜像 的 详细 过 程 。 


11.4.1 FROM 命令 


FROM 命令 一 般 都 是 Dockerfile 中 的 首 条 命令 ， 花 跟 其 后 的 参数 
为 具体 的 镜像 名 称 ， 意 味 着 整个 build 的 流程 都 将 此 镜像 作为 基础 镜 
像 。 虽然 作为 build 流 程 的 基础 镜像 ,但 是 依 | 日 没有 谈 及 实现 方式 。 此 
时 ,buildFile 这 个 对 象 就 体现 了 重要 的 作用 ， 很 多 命令 的 结果 都 会 在 
buildFile 对 象 中 有 所 体现 。 在 这 里 ,FROM 命令 的 基础 镜像 信息 会 被 
记录 到 buildFile 对 象 中 ,其 中 与 image 对 象 对 应 的 属性 值 为 


buildFile.image。 
FROM 命令 的 执行 流程 图 如 图 11-6 所 示 。 


从 图 11-6 中 ， 我 们 可 以 发 现 对 于 FROM 命令 后 的 镜像 参数 ， 
Docker Daemon 首 先 在 daemon.repository 中 查找 指定 的 镜像 ， 若 
镜像 不 存在 ， 即 立即 执行 镜像 下 载 任务 ，Docker 镜 像 的 下 载 可 以 参见 
第 9 章 ; 若 镜像 存在 ， 则 获取 镜像 信息 ， 并 开始 buildFile 配 置 流程 。 
配 葡 buildFile 的 作用 是 将 镜像 的 信息 加 载 至 buildFile。 关 于 FROM 命 
令 的 解析 工作 ， 源 码 位 于 

Wo 


if image.Config != ni 
b.config = image.Config 


if b.config.Env == nil || len(b.config.Env) == 0 { 
b.config.Env = append(b.config.Env, "PATH="+DefaultPathEnv) 
} 






镜像 存在 吗 ? 


印章 buildFile 


11-6 FROM 命 令 执行 流程 图 


分 析 以 上 源码 可 以 发 现 ，Docker Daemon 首 先 获取 镜像 ID , 将 
值 传 给 buildFile 的 image 属 性 。 如 此 一 来 ，build 流 程 的 基础 镜像 信 
息 已 经 获取 ， Dockerfile 的 第 二 条 命令 可 以 在 此 基础 镜像 的 基础 上 来 
完成 。 当 然 ，buildFile 的 image 属 性 也 会 随 着 build 流 程 的 变化 而 变 
化 。 举 一 个 最 简单 的 例子 ， 第 三 条 命令 就 会 依赖 第 二 条 命令 构建 完 之 
后 的 image。 回 到 buildFile 的 配置 ， 以 上 代码 表明 若 镜像 config 信 息 
存在 ， 则 将 镜像 的 config 信 息 传递 至 buildFile 的 config 属 性 ; 而 
config 属 性 中 的 Env 属 性 若 为 空 ， 则 在 Env 属 性 中 添加 默认 PATH ， 常 
量 为 DefaultPathEnv ,如 下 : 


const DefauLtPathEnv = 
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" 


cmdFrom 执 行 的 最 后 环节 是 配置 buildFile 的 OnBuild 属 性。 


总 之 , CmdFrom 完 成 基础 镜像 的 加 载 ， 通 过 buildFile 对 象 初始 
化 build 流 程 所 需 的 配置 信息 。 


11.4.2 ”RUN 命令 


RUN 命 令 在 build 流 程 中 扮演 着 非常 重要 的 角色 ，, 它 允 许 在 镜像 
的 基础 上 执行 用 户 指定 的 命令 。RUN 不 同 于 其 他 仅 修 改 镜像 config 信 
息 的 命令 ， 前 者 执行 用 户 指定 的 命令 ,这 意味 着 需要 在 镜像 基础 上 执 
行动 态 的 命令 ， 执 行 命令 时 存在 “容器 ”的 概念 


RUN 命 令 的 执行 通过 CmdRun 函 数 来 完成 ， 源 码 实现 位 
于 ./docker/docker/daemon/build.go#L27 6-L320 ,简化 后 如 


下 : 


func (b *buildFile) CmdRun(args string) error { 


b.config.Cmd = config.Cmd 
hit, err := b.probeCache() 
if err != nil { 

return err 


if hit { 
return nil 


} 
c, err := b.create() 


if err := b.commit(c.ID, cmd, "run"); err != nil { 
return err 


return nil 


分 析 以 上 源码 ,可 以 归纳 总 结 出 CmdRun 孙 数 的 执行 流程 图 ,如 
11-7 所 未 。 


配置 bulildFile 



















probeCache? 
N 






返回 nil 
图 11-7 CmdRun 也 数 的 执行 流程 图 
CmdRun 峭 数 的 执行 流程 图 ， 可 请 步 步 精 要 ， 每 一 个 步 又 在 
Docker 架 构 中 都 是 一 个 非常 重要 的 概念 。 以 下 从 probeCache、 


b.create( ) 、c.Mount( ) 、b.run( c) 以 及 b.commit( ) 这 5 
个 方面 进行 分 析 。 


1. 镜 像 cache 机 和 制 | 


首先 分 析 probeCache , 一 起 来 领略 Docker 在 build 流 程 中 巧妙 
使 用 镜像 cache 的 精彩 。 镜 像 cache 的 重用 意味 着 构建 相应 的 命令 
时 ， 不 再 执行 RUN 命 令 后 的 整 条 命令 , 而 从 Docker Daemon 本 地 的 
镜像 中 找 出 效果 与 执行 该 命令 相同 的 镜像 ， 作 为 结果 返回 。 


实现 原理 也 不 难 理解 。 由 于 Docker Daemon 在 build RUN 命 令 
之 前 ，buildFile 的 属性 image 肯 定 有 一 个 值 ( 基础 镜像 的 ID 或 者 后 续 
履 兰 基础 镜像 的 镜像 ID) ; 又 由 于 在 执行 build RUN 命 令 时 ，Docker 
Daemon 首 先 需 要 配置 buildFile 的 config 属 性 ， 实 则 是 在 
buildFile.image 的 config 属 性 上 进行 配置 。 因 此 ，Docker 
Daemon 只 需 遍 历 本 地 所 有 镜像 ， 只 要 存在 一 个 镜像 ,此 镜像 的 父 镜 
像 1D 与 当前 buildFile 的 image 值 相等 ， 同 时 此 镜像 的 config 内 容 与 
buildFile.config 相 同 ， 则 完全 可 以 认为 执行 RUN 命 令 产 生 的 结果 与 
此 镜像 的 效果 一 致 ， 直 接 使 用 本 地 存储 的 此 镜像 即 可 ， 无须 额 外 再 创 
建 。 知 不 存在 满足 条 件 的 镜像 ， 则 说 明 将 要 构建 的 新 镜像 在 本 地 还 不 


存在 ， Docker Daemon 必 须 完整 执行 RUN 命 令 。 
2 .创建 Container 对 象 


不 能 使 用 镜像 Cache 机 制 ， 意味 Docker Daemon 没 有 捷径 可 
走 ， 随 后 的 流程 是 创建 Container 对 象 ， 为 运行 容器 做 准备 。 


运行 Docker 容 硕 之 前 ,Docker Daemon 会 为 其 创建 一 个 
Container 对 象 ， RUN 命令 执行 流程 中 c, err : =b.create( ) 即 创 
建 了 一 个 Container 类 型 的 实例 c。 在 Docker Daemon 的 范畴 内 ， 创 
建 一 个 Container 对 象 ， 只 需要 基础 镜像 的 ID， 以 及 运行 容器 时 所 需 
的 runconfig 信 息 ， 而 这 些 信息 在 build 流 程 中 都 被 buildFile 统 一 
理 。 函 数 create 的 定义 位 
于 ./docker/docker/daemon/build.go#L752-L771 , 如 下 : 


func (b *buildFile) create() (*Container, error) { 
if b.image == "" { 
return nil, fmt.Errorf("Please provide a source image with 'from' 
prior to run") 


b.config.Image = b.image 
// Create the container 
c, , err := b.daemon.Create(b.config, "") 
if err != nil { 
return nil, err 
} 
b.tmpContainers[c.ID] = struct{}{} 
fmt.Fprintf(b.outStream, " ---> Running in %s\n", utils.TruncateID(c.ID)) 
// override the entry point that may have been picked up from the base image 
c.Path = b.config.Cmd[0] 


c.Args = b.config.Cmd[1:] 
return c, nil 


以 上 代码 中 ,涉及 的 config 参 数 有 当前 镜像 的 D、 所 有 的 
buildFile config 信 息 以 及 config 中 的 Cmd 信 息 ( 包括 Cmd 的 路 径 以 
及 Cmd 的 参数 ) 


3. 挂 载 文 件 系统 


RUN 命 令 需要 在 容 希 中 运行 指定 的 程序 , 故 仅仅 创建 Container 
类 型 实例 c 还 不 足以 支撑 容 怖 的 运行 。CmdRun 仍 然 需要 为 容 怖 的 运 
行 挂 载 文件 系统 ,c.Mount  ) 即 实现 了 这 部 分 功能 。 由 于 
Container 类 型 实例 c 中 包含 镜像 的 ID， 因 此 Docker Daemon 根 据 
该 镜像 ID， 追 溯 出 此 ID 的 所 有 祖先 镜像 ， 并 将 所 有 镜像 通过 指定 的 
graphdriver 完 全 联合 起 来 ， 挂 载 到 同一 个 目录 下 。 而 后 容器 的 运行 
将 使 用 该 挂 载 点 ， 作 为 容 怖 的 根 目 录 。 


4. 运 行 容器 


运行 Docker 容 莫 ， 绝 对 是 Docker 体 系 中 的 重头 戏 。 如 果 容 姨 缺 
少 了 动态 的 运行 时 ,对 于 用 户 而 言 ，Docker 就 显得 没有 丝毫 吸引 力 。 


为 容 医 的 运行 创建 了 Container 类 型 实例 c 之 后 , CmdRun 即 利 
用 c 中 众多 的 容器 配置 信息 , 将 Docker 容 器 运行 起 来 。 在 这 一 过 程 
中 ,Docker Daemon 完 成 的 工作 有 很 多 ,包括 : 创建 容 钴 的 文件 系 
统 ， 创建 容 问 的 命名 空间 进行 做 资源 隔离 ， 为 容器 配置 Cgroups 参 数 
进行 资源 控制 ， 当 然 ， 还 有 运行 用 户 指定 的 程序 等 。 运 行 容 希 举 足 轻 
重 ， 这 部 分 内 容 将 在 第 12 章 详细 展开 。 


5 .提交 新 镜像 


Das DO 


运行 完 容 磊 ，DockerDaemon 需 要 对 运行 后 的 容 希 进行 commit 


操作 ， 将 容 恬 运 行 的 结果 保存 在 一 个 新 的 镜像 中 ， 换 言 之 ,将 更 改 后 


的 top layer 制 作成 一 个 新 镜像 ， 并 有 效 存 储 。 需 要 注意 的 是 ， 
commit 操 作 在 执行 完 容 蓝 命令 之 后 ， 入 
却 有 不 少 难 度 。 一 旦 RUN 命 令 之 后 紧 跟 的 命令 是 无 限 循环 的 命令 ,或 
者 不 会 退出 的 命令 ， 容 器 运行 就 不 会 退出 ， 这 将 导致 整个 Dockerfile 
build 流 程 的 阻塞 。 


回 到 buildFile 的 commit 操 作 ,，RUN 命 令 的 commit 操 作 和 其 他 
命令 的 commit 操 作 稍 有 不 同 。RUN 命 令 的 commit 操 作 是 从 一 个 
行 完毕 的 容器 中 保存 文件 系统 中 的 Read-Write 层 ， 以 一 个 镜像 的 形式 
存 入 本 地 graph 中 。buildFile 的 commit 汐 数 直 接 调用 daemon 包 中 
的 Commit 辐 数 ， 源 代码 位 
于 ./docker/docker/build/daemon.go#853 , 如下: 


image,err:=b.daemon.Commit(container,"","","",b.maintainer,true,&autoConfig) 


而 daemon 包 的 Commit 驹 数 的 执行 流程 包含 如 下 4 个 步 又。 


LA 


) 暂停 Docker Container 的 运行 。 这 一 步骤 对 于 Dockerfile 中 
的 RUN 命 令 不 起 作用 ,原因 是 CmdRun 命 令 只 有 在 命令 完全 执行 完 
, Docker 容 兹 终止 运行 之 后 ， 才 执行 Commit 操 作 。 然 而 ， 对 于 一 
正在 运行 的 容 右 ，Docker 同 样 支持 为 容 右 提交 一 个 镜像 ， 而 此 时 
commit 操 作 的 第 一 步 即 为 停止 容 闫 的 运行 ， 保 存 容器 运行 的 现场 。 


2) 把 容器 文件 系统 的 Read-Write 层 打 成 tar 包 。 由 于 在 容器 的 
运行 过 程 中 所 有 写 操作 都 只 会 作用 于 文件 系统 中 的 top layer( 即 
Read-Write 层 ) ， 故 容器 运行 过 程 中 文件 系统 的 增 量变 化 都 在 Read- 
Write 层 ， 将 该 层 打包 即 可 获得 新 镜像 的 文件 系统 内 容 。 


3) 创建 Image 对象 ， 并 在 Graph 中 注册 。 新 的 tar 包 即 为 镜像 的 
原材料 ， 通 过 tar 包 ， 以 及 众多 配置 信息 ，DockerDaemon 为 其 创建 
一 个 image 对 象 。 最 后 通过 graph.Register ) 函数 实现 在 Graph 
中 注册 该 镜像 。graph.Register( ) 尔 数 相信 大 家 一 定 不 会 卫生 ,第 
10 章 已 经 分 析 了 该 兽 数 的 实现 。 


4) 在 Docker 的 repositories 中 注册 新 创建 的 镜像 。 对 象 
repositories 的 类 型 实则 为 TagStore , TagStore 的 Repositories 属 
性 即 存储 了 image 的 信息 ， 便 于 用 户 快速 查找 。 


回 到 buildFile 的 CmdRun 函 数 ,执行 commit 操 作 之 后 ， 立 即 返 
回 创建 的 新 镜像 ， 而 将 该 镜像 的 ID 作 为 下 一 个 Dockerfile 命 令 执行 的 
基础 镜像 ， 源 代码 为 b.image=image.ID， 同 时 CmdRun 响 数 也 执 


一 


行 完 毕 。 


11.4.3 ENV 命令 


ENV 命 令 的 含义 为 : 构建 镜像 时 ， 为 镜像 添加 一 个 环境 变量 。 
ENV 命 令 可 以 有 效 帮 助 用 户 自 定 义 Docker 镜 像 的 环境 变量 ， 以 至 于 
通过 镜像 运行 容器 时 ， 容 器 进程 能 拥有 用 户 定义 的 环境 变量 。 


执行 ENV 命 令 的 水 数 为 CmdEnv , CmdEnv 的 主要 工作 即 为 在 
buildFile.image 的 基础 上 ，, 配置 指定 buildFile.config 中 的 Env 参 
数 。 随 后 执行 Commit 操 作 ， 源 码 实现 如 下 : 


b.commit("", b.config.Cmd, fmt.Sprintf("ENV %s", replacedVar)) 


执行 以 上 代码 将 创建 一 个 新 镜像 ， 并 运行 完 daemon 包 中 的 
Commit 纹 数 。 虽 然 创建 镜像 过 程 中 不 会 有 新 的 文件 系统 变化 ， 但 是 
对 于 镜像 而 言 ， 镜 像 的 json 信 息 已 经 发 生 明显 的 变化 ， 即 镜像 的 json 
信息 中 ENV 部 分 被 修改 。 


11.5 总 结 


Dockerfile build 的 流程 是 不 断 创建 新 镜像 的 过 程 。 有 的 镜像 包 
含 文件 系统 的 内 容 ， 这 意味 着 镜像 创建 过 程 中 ， 容 兹 的 Read-Write 层 
被 修改 ; 有 的 镜像 内 容 为 空 ， 即 不 包含 文件 系统 的 内 容 ， 这 意味 着 镜 
像 创 建 过 程 中 ， 仅 仪 修改 了 镜像 的 json 信 息 。 


Dockerfile 的 存在 ， 使 得 软件 有 能 力 与 运行 环境 一 同 以 一 种 非常 
轻 量 级 的 方式 分 发 。 不 论 是 软件 的 发 布 ， 还 是 软件 的 管理 方面 ， 
Dockerfile 都 大 大 释放 了 软件 的 生命 力 。 本 章 即 从 docker build 的 流 
程 入 手 ， 从 原理 的 角度 分 析 了 构建 镜像 的 全 过 程 。 熟 悉 docker build 
的 流程 ， 对 于 编写 高 效 、 合 理 的 Dockerfile， 具有 非常 大 的 帮助 。 


第 12 音 ”Docker 容 器 创建 
12.1 引言 


云 计算 时 代 ， 随 着 Docker 的 异 车 突起 ， 工 业界 刊 过 阵 阵 容 状 的 巾 
风 。 飓 风 所 至 之 处 ， 圈 内 人 士 纷纷 探讨 Docker 与 传统 虚拟 化 技术 的 异 
同 。 传 统 的 虚拟 化 技术 ， 如 KVM、Xen 等 ， 在 过 去 的 数 年 间 已 经 受到 
行业 的 检验 ， 虽 然 不 是 尽善尽美 ， 但 给 工业 界 带 来 的 好 处 也 足以 让 世 
人 对 其 称赞 。Docker 的 诞生 并 不 是 为 了 蔡 代 传 统 的 虚拟 化 技术 ， 然 
而 ， 它 的 诞生 却 让 人 如 拿 着 放大 镜 般 地 看 待 传统 虚拟 化 技术 的 弊病 。 
可 以 说 ，Docker 指 明了 又 一 条 虚拟 化 道路 ; 或 许 说 Docker 折 充 了 虚 
拟 化 的 范畴 。 传 统 的 虚拟 化 技术 主要 用 于 提供 基础 设施 的 服务 ， 而 
Docker 在 隔离 与 控制 计算 资源 的 同时 仍然 可 以 融入 用 户 的 应 用 逻辑 ， 
基础 设施 和 上 层 应 用 的 界限 被 打破 。 存 在 即 合理 ， 风 靡 全 球 更 说 明了 
Docker 满 足 了 用 户 以 往 那些 被 认为 天 方 夜 谭 的 需求 。 


一 直 认 为 Docker 可 以 提供 “ 容 硕 "服务 ， 正 是 Docker 提 供 的 ”“ 容 
硕 "” 会 经 常用 来 与 “虚拟 机 "比较 。 很 多 比较 的 维度 大 家 肯定 不 阳 生 ， 
比如 :“ 容 需 " 运 行 时 与 销 主 机 共享 同一 个 操作 系统 ， 节 省 物理 资 
源 ;“ 容 器 "的 局 动 非常 快 ， 甚 至 可 以 达到 秒 级 ,“ 容 问 " 运 行 时 MO 性 能 
明显 高 于 虚拟 机 ……: 工 业界 对 两 者 的 比较 肯定 比 以 上 罗列 的 更 全 面 、 


更 具体 。 然 而 ， 似 乎 很 多 观点 都 和 “容器 ”的 运行 息息相关 。 而 “ 容 
右 ” 的 运行 人 到底 是 何 种 情况 ? 本 章 将 以 Docker 为 例 ， 展现 Docker 容 器 
运行 的 始末 。 


本 章 主 要 从 源码 的 角度 分 析 用 户 发 起 docker run 命 令 之 后 ， 整 个 
Docker 体 系 中 的 组 件 如 何 协同 工作 ,最终 实现 Docker 容 希 的 运行 。 
本 书 的 分 析 均 基于 Docker 1.2.0 版 本 ,libcontainer 的 版 本 也 为 
1.2.0。 本 章 主要 内 容 包含 以 下 三 个 方面 : 


1) 简要 讲述 Docker 容 器 运行 的 流程 , 即 从 Docker Client、 
Docker Server 以 及 Docker Daemon 的 角度 前 述 docker run 命 令 的 


执行 流程 ; 
2) 详细 分 析 Docker Daemon 创建 容器 对 象 的 过 程 ; 


3) 详细 分 析 Docker Daemon 局 动容 背 的 过 程 。 


12.2 Docker 容 左 运 行 沉 程 


一 位 精通 Docker 的 好 于 ， 对 于 docker run 命 令 的 使 用 绝对 了 然 于 
胸 。 此 命令 帮助 Docker 用 户 在 指定 配置 下 完成 Docker 容 需 的 运行 ， 
并 运行 用 户 指定 的 程序 。Docker 架 构 中 ， 几 乎 所 有 的 操作 均 与 docker 
run 有 莫大 的 关联 。 镜 像 下 拉 命 令 docker pull ,目标 正 是 通过 docker 
run 命 令 在 镜像 的 基础 上 运行 容 希 ; 镜像 构建 命令 docker build ， 
Dockerfile 中 涉及 RUN 命 令 ， 每 执行 一 个 RUN 命 令 ， 均 会 运行 一 个 
Docker 容 颖 ,并 对 容 旭 进 行 Commit 操 作 ， 打 包容 比 镜像 ; 而 Docker 
中 设置 网 络 模式 、 容 器 互联 ( link) 等 操作 ， 均 需要 在 容器 运行 前 给 


docker run 命 令 指定 参数 。 


命令 docker run 与 其 他 命令 无 差别 ， 执 行 流程 均 由 Docker 
Client、Docker Server 以 及 Docker Server 协 同 完 成 。 第 7 章 分 析 
Docker 容 希 的 网 络 时 曾 分 析 过 此 执行 流程 ， 此 流程 图 如 图 12-1 所 示 
( Docker Server 仅 负责 路 由 转发 ， 图 中 并 未 显著 标 出 ) 
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12-1 docker run 命 令 执行 流程 图 


图 12-1 表 明 , Docker Client 共 发 送 了 两 次 POST 请 求 至 Docker 
Daemon。 第 一 次 请 求 试图 让 Docker Daemon 通 过 请 求 中 的 镜像 信 
息 ， 创建 容 强 对 象 ; 第 二 次 请 求 则 通知 Docker Daemon 局 动容 兹 ， 
使 得 容器 处 于 运行 状态 。 对 于 Docker Client 而 言 ,docker run 命 令 
的 所 有 参数 都 需要 处 理 成 Docker Daemon 可 以 识别 的 形式 ， 为 此 
Docker 的 设计 者 设计 了 Docker Client 与 Docker Daemon 均 可 以 识 
别 的 两 个 数据 结构 config 与 hostconfig， 来 存储 所 有 命令 参数 。 关 于 
config 结 构 体 与 hostconfig 结 构 体 的 描述 与 分 析 ， 可 以 参见 7 .3.2 节 。 


CmdRun 


parse config, 





ee 与 hostconfig 中 包含 的 参数 信息 ， 本 章 使 用 
以 下 docker run 命 令 进 行 举例 分 析 : 


docker run -m 104857600 -P --net=bridge -v /home/test:/home/test -v /data -e 
TEST_ENV=myenv --name ubuntu test --link db:db ubuntu:14.04 





以 上 命令 中 参数 的 分 析 如 表 12-1 所 示 。 


表 12-1 docker run 命 令 参 数 解析 
































-m -m 104857600 | 为 容器 运行 设置 内 存 上 限 104857600 字 节 ， 即 100MB 

2 学 将 容器 内 EXPOSE 的 端口 均 暴 露 至 宿主 机 

--net --net=bridge 容 需 运行 时 使 用 bridge (桥接 ) 网 络 模式 

-V -Vv /home/test:/home/test 将 宿主 机 目录 /home/test 挂 载 至 容器 的 /homey/test 

-Vv /data 为 容器 创建 一 个 非 绑 定 挂 载 (bind-mount) 的 data volume /data 
-e —e TEST_ENV=myenv 为 容器 添加 环境 变量 TEST_ ENV， 值 为 myenv 

--name --name Ubuntu test 为 容器 设置 名 称 ubuntu_test 

--link --link db:db | 将 容器 db 以 别名 db 的 形式 链接 到 创建 的 容器 中 


Docker Client 的 参数 解析 工作 是 : 处 理 类 似 以 上 的 参数 并 存 入 
config 或 者 hostconfig , 最 后 分 别 通过 两 次 POST 请 求 发 送 至 Docker 
Daemon。Docker Client 与 Docker Server 解 析 处 理 请 求 的 分 析 ， 
本 章 已 经 提 及 过 ， 故 不 册 歼 述 。 本 章 仅 从 Docker Daemon 两 次 处 理 
并 响应 POST 请 求 入 手 ， 还 原 Docker 容 希 运 行 的 现场 。 


12.3 Docker Daemon 创 建 容 器 对 象 


Docker 容 咒 的 运行 并 非 只 是 简单 地 调用 内 核 接 口 ，Docker 的 设 
计 者 有 意 将 配置 信息 与 局 动容 背 的 操作 进行 区 分 ， 实 现 数据 与 逻辑 的 
有 机 分 离 。 


Docker 用 户 指定 的 众多 参数 ， 以 及 Docker 镜 像 中 的 众多 参数 ， 
在 运行 容 硕 时 ， 均 可 以 认为 是 Docker 容 希 的 配置 信息 来 源 。 当 第 一 次 
接收 到 Docker Client 发 送 的 POST 请 求 后 ,Docker Daemon 开始 创 
建 容 蓝 对象 container ,处 理 并 整理 用 户 指定 与 镜像 指定 的 config 信 
息 。 创 建 container 对 象 的 源码 实现 位 
于 ./docker/docker/daemon/create.go#L56-L86 , 如 下 : 


// Create creates a new container from the given configuration with a given name. 
func (daemon *Daemon) Create(config *runconfig.Config, name string) (*Container, 
[]string, error) { 
var ( 
container *Container 
warnings []string 
) 
img, err := daemon.repositories.LookupImage(config,Image) 
if err != nil { 
return nil, nil, err 
} 


if err := img.CheckDepth(); err != nil { 
return nil, nil, err 


if warnings, err = daemon.mergeAndVerifyConfig(config, img); err != nil { 
return nil, nil, err 


if container, err = daemon.newContainer(name, config, img); err != nil { 
return nil, nil, err 


if err := daemon.createRootfs(container, img); err != nil { 
return nil, nil, err 

} 

if err := container.ToDisk(); err != nil { 


return nil, nil, err 


} 


if err := daemon.Register(container); err != nil { 
return nil, nil, err 


return container, warnings, nil 


Create 哨 数 的 逻辑 极其 清晰 ， 从 起 初 声 明 container 对 象 ， 到 最 
后 返回 container , 中 间 环 节 的 逻辑 完全 属于 顺序 执行 。 表 12-2 给 出 
了 中 间 各 环节 执行 的 困 数 与 作用 。 


表 12-2 Create 函数 执行 步骤 解析 








执行 函数 名 称 执行 函数 作用 
LookupImage 在 daemon 对 象 的 repositories 属性 中 查找 用 户 指定 镜像 
CheckDepth 检验 镜像 的 layer 总 数 ， 镜 像 层 总 数 不 能 超过 127 





mergeAndVerifyConfig 


将 用 户 指定 的 config 参数 与 镜像 json 文件 中 的 config 合并 并 验证 








newContainer 创建 新 的 container 对 象 
createRootfs 创建 属于 container 对 象 的 rootfs 
ToDisk 将 container 对 象 json 化 之 后 写 入 本 地 磁盘 进行 持久 化 





Register 





在 Docker Daemon 中 注册 该 新 建 的 container 对 象 


12.3.1 Lookuplmage 


创建 并 且 运 行 一 个 Docker 容 闫 ,同样 需要 原材料 ， 这 样 的 原材料 
是 : Docker We 而 Lookuplmage 
六 数 的 功能 即 为 : 通过 用 户 指定 的 镜像 名 称 ， 从 daemon 的 
repositories 对 象 中 查找 镜像 。Docker 镜 像 的 概念 已 经 在 Docker 
Daemon 的 多 个 概念 中 出 现 过 ， 如 对 象 daemon.repositories 的 类 型 
为 TagStore， 以 及 类 型 Graph 与 类 型 Driver 等 。 这 三 种 结构 体 之 间 的 
关系 如 图 12-2 所 示 : 


Sync. RWMutex 









trie *patricia. Tree 


ids maplstring]struct {} 
Graph 


Root string 
idIndex *truncindex. Trunclndex 


driver graphdriver. Driver Driver (aufs) 


root string 


TagStore | sync. Mutex 
active map[string]string 


path string 

graph *Graph 

Repositories map[string]Repository 
sync. Mutex 







pullingPool map[string]jchan struct{) Repository map[string]string 
pushingPool map[string]jchan struct{} 


12-2 TagStore、Graph 以 及 Driver 之 间 的 关系 


Docker Daemon 每 次 成 功 下 载 一 个 含有 tag 的 镜像 ， 或 者 每 次 成 
功 构建 一 个 镜像 ， 最 后 的 步骤 都 是 将 这 个 镜像 在 


daemon.Repositories 中 注册 , 若 graghdriver 的 类 型 为 aufs ,， 则 镜 
像 注册 会 写 入 本 地 文件 /varlib/dockerrepositories-aufs 文 件 中 。 文 
件 repositories 的 存在 ， 使 得 Lookuplmage 上 男 数 的 实现 变 得 异常 角 
单 ，Lookuplmage 肯 数 的 源码 实现 位 

于 ./dockerdockergraph/tags.go#L79-L97 ,如 下 : 


func (store *TagStore) LookupImage(name string) (*image.Image, error) { 
// FIXME: standardize on returning nil when the image doesn't exist, and 
err for everything else 
// (so we can pass all errors here) 


repos, tag := parsers.ParseRepositoryTag(name) 
If tag == "" 
tag = DEFAULTTAG 
3 
img, err := store.GetImage(repos, tag) 


store.Lock() 
defer store.Unlock() 
if err != nil { 
return nil, err 
} else if img == niL { 
if img, err = store.graph.Get(name); err != nil { 
return nil, err 


return img, nil 


Docker Daemon 需 要 用 户 指 定 镜 像 名称 ， 而 Lookuplmage 哨 数 
第 一 步 即 解析 用 户 指定 镜像 的 镜像 名 称 与 镜像 tag， 奉 tag 为 空 ， 则 默 
认 设 为 “latest"。 紧 接着 , Docker Daemon 通 过 repos( 镜像 名 称 ) 
与 tag 信 息 , 尝试 从 TagStore 的 graph 属 性 中 提取 img 对 象 。Docker 
Daemon 完 全 通过 以 上 步 又 得 有 img 对 象 ， 从 而 获取 在 本 地 文件 系统 
中 的 镜像 layer， 以 及 该 镜像 json 文 件 中 的 配置 信息 。 


12.3.2 CheckDepth 


Docker Daemon 找 到 对 应 的 镜像 之 后 ， 对 镜像 进行 简单 的 
验证 。 若 用 户 指定 的 Docker 镜 像 加 上 所 有 祖先 镜像 之 后 ， 镜 像 layer 
总 数 达 到 很 大 数量 ， 则 通过 aufs 对 所 有 layer 执 行 Union Mount 操 作 
将 会 造成 不 小 的 性 能 问题 。 最 大 的 问题 就 是 : 系统 实现 文件 读 与 时 ， 
查找 文件 inode 的 时 间 变 长 。 因 此 ，Docker Daemon 会 对 用 户 指定 
镜像 的 深度 进行 检验 ， 源 码 位 
于 ./docker/docker/image/image.go#L308-L319 , 如 下 : 


func (img *Image) CheckDepth() error { 


// We add 2 layers to the depth because the container's rw and // init layer 
add to the restriction depth, err := img.Depth() if err != nil 


return err } 
if depth+2 >= MaxImageDepth { 


return fmt,Errorf("Cannot create container with more than %d 
parents", MaxImageDepth) } 


return nil 


Docker Daemon 局 动容 希 前 ， 需 要 通过 镜像 为 容 闫 准备 
rootfs， 由 于 通过 aufs 联 合 layer 时 ， 会 在 镜像 的 top layer 之 上 ,再 
丢 加 两 个 layer， 分别 为 init layer 和 容器 的 read-write layer。 故 
CheckDepth 钠 数 计 算出 指定 镜像 的 深度 之 后 ， 确保 容 缆 镜像 的 深度 
值 加 2 仍 小 于 最 大 镜像 深度 MaxlImageDepth。MaxlmageDepth 的 


值 为 常量 127 。 


12.3.3 mergeAndVerifyConfig 


分 析 Docker 的 镜像 技术 时 ， 有 一 点 内 容 经 常 容 易 被 名 略 ， 那 就 
是 : Docker 镜 像 不 仅 包含 文件 系统 中 静态 的 文件 内 容 ， 还 包含 该 镜像 
的 json 文 件 信息 。 而 json 文 件 包含 镜像 的 众多 描述 信息 ， 包 括 镜像 的 
ID、 镜 像 提交 时 的 容 磺 ID ， 以 及 镜像 详尽 的 Config 配 置信 息 。 


Docker 镜 像 含 有 config 信 息 , docker run 命 令 传 入 的 许多 参数 
信息 也 是 以 runconfig.Config 的 形式 转交 至 Docker Daemon。 


两 份 Config 信 息 如 何在 运行 容 莫 时 各 自 起 到 相应 的 作用 ,是 
Docker Daemon 应 该 考虑 的 问题 。 而 mergeAndVerifyConfig 卫 数 
则 巧妙 地 将 两 者 有 机 结合 在 一 起 ， 实 现 鹃 数 为 runconfig 包 中 的 
Merge 郧 数 。 函 数 mergeAndVerifyConfig 的 定义 位 
于 ./docker/docker/dameon/daemon.go#L399-L413 , 如 下 : 


func (daemon *Daemon) mergeAndVerifyConfig(config *runconfig.Config, img 
*image.Image) ([]string, error) 

warnings := []string{} 

if daemon.checkDeprecatedExpose(img.Config) || daemon.check- 
DeprecatedExpose(config) { 
warnings = append(warnings, "The mapping to public ports on your 

host via Dockerfile EXPOSE (host:port:port) has been deprecated. Use -p to 
publish the ports.") 
} 


if img.Config != nil { 
if err := runconfig.Merge(config, img.Config); err != nil { 
return nil, err 


} 
if len(config.Entrypoint) == 0 AR& len(config.Cmd) == 0 { 
return nil, fmt.Errorf("No command specified") 


return warnings, nil 


函数 mergeAndVerifyConfig 除 了 merge 之 外 ， 自 然 还 包括 
Verify 和 Config， 若 合并 之 后 的 config 对 象 中 不 存在 Entrypoint 并 和 且 
也 没有 Cmd ，, 则 说 明 整 个 容 问 没有 局 动 入 门 ，Docker Daemon 必 须 
对 这 种 情况 返回 错误 。 


12.3.4 NewContainer 


Docker Daemon 创 建 容 部 对 象 的 第 4 个 步 又 是 : 使 用 
newContainer 六 数 新 建 并 初始 化 container 对 象 。newContainer 
闹 数 的 实现 过 程 很 清晰 ,创建 并 初始 化 hewContainen 间 数 内 部 的 
container 对 象 的 源码 位 
于 ./docker/docker/daemon/daemon.go#L529-L548 , 如 下 : 


container := &Containert{ 


// FIXME: we should generate the ID here instead of receiving it as an 


argument ID: id, 
Created: time.Now() .UTC(), Path: entrypoint, Args: 
args, //FIXME: de-duplicate from config Config: config, 
hostConfig: &runconfig.HostConfig{}, Image: img.ID, // 
Always use the resolved image id NetworkSettings: &NetworkSettings{}, Name: 
name, 
Driver: daemon.driver.String(), ExecDriver: 
daemon .execDriver.Name(), State: NewState(), } 


container.root = daemon.containerRoot(container.ID) if container.ProcessLabel, 
container.MountLabel, err = label.GenLabels(""); err != nil { 


return nil, err 


其 中 需要 特别 说 明 的 是 Path 属 性 ，Path 属 性 的 值 为 
entrypoint。 众 所 周知 , entrypoint 是 Docker 容 器 运行 时 非常 重要 
的 概念 。 用 户 一 旦 指定 entrypoint, 则 Docker 运 行 容 莫 时 ， 可 以 首 
先 执行 entrypoint 的 内 容 ( 一 般 为 脚本 ) ， 而 entrypoint 的 最 后 一 行 
脚本 命令 一 般 是 exec 用 户 指定 的 Cmd ,届时 才 开 始 运行 用 户 指定 的 
应 用 进程 。 这 样 的 好 处 很 明显 ， 局 动容 硕 时 的 工作 分 为 两 部 分 : 第 
一 ， 和 运行 entrypoint， 完 成 与 系统 配置 或 初始 化 相关 的 工作 ; 第 二 ， 
运行 Cmd， 开 始 执行 用 户 应 用 程序 。 


12.3.5 createRootfs 


完成 以 上 四 个 步骤 ， 原则 上 已 经 成 功 创建 了 container 对 象 。 此 
时 Docker Daemon 并 未 直接 返回 container 对 象 ， 而 是 在 此 基础 上 
完成 容 旨 文 件 系统 rootfs 的 配置 。 文 件 系 统 rootfs 的 挂 载 ， 其 实 要 比 
第 8 章 涵盖 的 内 容 更 多 。 通 过 用 户 指定 的 镜像 ，Docker Daemon 完 
全 有 能 力 将 所 有 layer 通 过 aufs 联 合 挂 载 起 来 ， 而 createRootfs 的 实 
现 则 是 在 联合 挂 载 所 有 镜像 layer 的 基础 上 ， 再 挂 载 两 个 layer , 一 层 
称 之 为 “init layer”, 另 一 层 则 为 大 家 熟知 的 “read-write layer”。 


在 createRootfs 喘 数 中 ， 创 建 init layer 以 及 read-write layer 
的 源码 实现 位 于 ./docker/docker/daemon/daemon.go#L568- 
L574 ,如 下 : 


if err := graph.SetupInitLayer(initPath); err != nil { 
return err 


if err := daemon.driver.Create(container.ID, initID); err != nil { 
return err 


graph 包 的 SetuplnitLayer 的 作用 是 : 在 镜像 基础 上 挂 载 一 系列 
与 镜像 无 关 而 与 容 颖 运行 环境 相关 的 目录 和 文件 ,如 /dev/pts、 
proc、.dockerinit、/etc/hosts、etc/hostname 以 


及 /etc/resolv.conf 等 。 需 要 特殊 说 明 的 是 : .dockerinit 为 


dockerinit 二 进 制 文件 挂 载 点 ， 而 dockerinit 是 Docker 容 器 中 第 一 个 
运行 的 内 容 。 第 13 章 将 详细 分 析 dockerinit 在 Docker 容 器 中 的 作 
用 。 


12.3.6 ToDIsk 


Docker Daemon 对 于 每 一 个 创建 的 容器 ， 均 会 将 其 json 化 后 持 
久 化 至 本 地 文件 系统 中 。ToDisk 甬 数 的 功能 正 是 如 此 。ToDisk 依 靠 
toDisk 绚 数 来 完成 ， 后 者 的 源 代 码 定 义 位 


于 ./docker/docker/daemon/container.go#L112-L129 , 如下: 
func (container *Container) toDisk() error { 

data, err := json.Marshal(container) if err != nil { 
return err } 

pth, err := container.jsonPath() if err != nil { 
return err } 

err = ioutil.WriteFile(pth, data, 0666) if err != nil { 
return err } 


return container.WriteHostConfig() } 


以 上 代码 清晰 明了 ， 它 不 仅 实 现 container 对 象 json 化 后 的 本 地 
持久 化 ， 还 实现 Container 中 hostConfig 对 象 的 本 地 持久 化 ， 最 为 重 


要 的 自然 是 确定 写 入 的 路 径 。 代 码 pth , err : = container.jsonPath 
( ) 即 获 取 json 文 件 的 放置 目 


录 /Varl/lib/docker/container/containers/< container id> 。 


12.3.7 Register 


container 对 象 创建 之 后 ， 并 根据 一 些 规则 对 其 进行 预 处 理 之 
后 , Docker Daemon 将 container 对 象 注册 至 daemon 的 
containers 属 性 。 注 册 的 内 容 为 Container 对 象 的 容 毁 ID。 注 册 的 意 
义 在 于 , Docker Daemon 此 后 可 以 通过 daemon 对 象 调 度 并 管理 这 
个 有 效 的 container 对 象 。 


Register 纹 数 执行 完毕 ,意味 着 Docker Daemon 创 建 容 器 对 象 
的 工作 全 部 完成 。 如 此 一 来 ， 万 事 俱 备 ， 只 和 欠 东 风 ，Docker 
Daemon 的 容 益 局 动 命令 一 触 即 发 。 


12.4 Docker Daemon 启 动容 器 


Docker 的 世界 中 ， 动 态 的 内 容 往往 更 加 迷人 。 静 态 的 内 容 ， 诸 如 
镜像 、Dockerfile、Docker Registry 等 ， 似 乎 都 是 为 了 服务 于 动态 
的 容 展 。12.3 节 中 的 container 对 象 的 创建 ， 也 仪 仪 是 静态 内 容 的 梳 
理 与 组 织 ， 仍 缺少 容 益 方 面 的 活力 。 


Docker Daemon 局 动容 顺 的 操作 取决 于 docker run 命 令 发 起 的 
第 一 个 POST 请 求 。 由 于 container 对 象 已 经 创建 ， 并 由 daemon 对 象 
管理 ， 故 POST 请 求 只 要 携带 container 的 ID 信 息 ,容器 启动 命令 就 能 
触发 。 


从 逻辑 的 角度 而 言 ,， Docker Daemon 仅仅 通 过 获取 container 对 
象 ， 并 执行 此 对 象 的 Start 纯 数 。 从 Start 函 数 的 具体 执行 内 容 而 言 ， 涉 
及 的 内 容 很 广泛 ， 图 12-3 详 细 说 明 Docker Daemon 针 对 container 
对 象 所 操作 的 具体 内 容 。 
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就 顺序 而 言 


图 12-3 ” Start 负数 涉及 内 容 示 意 


, Docker Daemon 执行 Start 纹 数 , 包含 以 下 11 个 步 


12.4.1 setupContainerDns 


一 个 功能 完善 的 Docker 容 肴 ， 肯 定 离 不 开 基本 的 网 络 能 力 。 出 色 
的 网 络 能 力 意味 着 容 兹 内 部 不 是 一 个 闭塞 的 环境 ， 容 况 可 以 与 外 界 建 
立 通 信 。 这 样 的 网 络 自然 离 不 开 DNS 服 务 ， 用 于 可 以 确保 域名 的 正常 
工作 。Docker Daemon 局 动容 关 的 第 一 个 步骤 就 是 配置 容 毁 的 DNS 
服务 。 


一 旦 Docker 容 需 的 网 络 模式 为 host 模 式 ， 则 容 项 和 宿主 机 共享 
同一 个 网 络 命名 空间 ， 容 怖 无 须 为 自身 的 DNS 服务 考虑 ， 完 全 使 用 宿 
主机 的 DNS 服务 。 如 若 不 然 ，Docker Daemon 则 需要 为 容 硕 内 部 配 
置 DNS 服 务 。 配 置 容 狠 DNS 的 源码 实现 位 
于 ./docker/daemon/container.go#L842-L979 , 如下: 


func (container *Container) setupContainerDns() error { 
resolvConf, err := resolvconf.Get() 


container.ResolvConfPath, err = container.getRootResourcePath("resolv.conf") 


if config.NetworkMode != "host" && (len(config.Dns) > 0 || 
len(daemon.config. 
Dns) > 0 || len(config.DnsSearch) > 0 || len(daemon.config.DnsSearch) 
> 0) { 
var ( 
dns resolvconf .GetNameservers(resolvConf) 


dnsSearch = resolvconf.GetSearchDomains(resolvConf) 
) 
if len(config.Dns) > 0 { 
dns = config.Dns 
} else if len(daemon.config.Dns) > 0 { 
dns = daemon.config.Dns 
} 


return resolvconf.Build(container,.ResolvConfPath, dns, dnsSearch) 


return ioutil.WriteFile(container,.ResolvConfPath, resolvConf, 0644) 


创建 容 莫 的 DNS 服 务 与 答 主 机 有 着 密 不 可 分 的 关系 。Docker 
Daemon 首 先 通 过 resolvconf.Get( ) 获取 宿主 机 
在 /etc/resolv.conf 文 件 中 的 DNS 信息 ; 随后 
在 /var/lib/docker/containers/< container id> 月 录 下 获取 
resolv.conf 文 件 的 路 径 ( 此 文件 最 终 会 被 挂 载 至 容 希 内 部 ) ; 若 容 希 
的 网 络 模式 不 为 host 模 式 ， 则 紧 接着 的 工作 是 Docker Daemon 判 断 
用 户 和 Docker Daemon 是 人 否 指定 DNS 地 址 ， 一 旦 指定 ， 则 使 用 指定 
的 DNS 地 址 。 


正如 上 面 提 及 的 ，Docker 用 户 启 动 Docker Daemon 和 局 动 
Docker 容 希 时 都 可 以 指定 DNS 地 址 。 当 用 户 使 用 docker run 命 令 局 
动容 莫 时 ， 若 使 用 -dns 参 数 ， 则 表明 用 户 需 要 为 容 莫 指定 DNS 地 址 
( 在 Docker Daemon 中 对 应 的 数据 结构 为 对 象 cConfig.Dns) 
Docker Daemon 优先 满足 Docker 用 户 指定 DNS 的 需求 。 若 用 户 没 
有 指定 -dns 参 数 ， 则 Docker Daemon 会 为 容 问 配置 Docker 
Daemon 的 DNS 地 址 。 如 果 用 户 在 启动 Docker Daemon 时 指定 - 
dns 参 数 ( 在 Docker Daemon 中 对 应 的 数据 结构 为 
daemon.config.Dns) ， 则 表明 默认 情况 下 ，Docker Daemon 会 
为 Docker 容 器 配置 该 DNS 地 址 。 当 用 户 启动 Docker Daemon 时 ， 
若 没 有 指定 -dns 参数 ， 并 且 宿 主机 /etc/resolv.conf 文 件 中 第 一 条 记 


录 的 DNS 地 址 为 127.0.0.1 或 者 127.0.1.1( 容 硕 内 部 使 用 这 两 个 
DNS 地 址 无 效 ) ， 则 Docker Daemon 采 用 默认 的 DNS 地 址 8.8.8.8 
和 8.8.4.4。 采 用 默认 DNS 地 址 并 不 会 一 劳 永 多。 特殊 情况 下 ， 
8.8.8.8 和 8.8.4.4 并 不 能 提供 稳定 可 靠 的 域名 解析 服务 ， 很 大 程度 上 
影响 Docker 容 器 的 使 用 。 若 用 户 没 有 指定 任何 -dns 参 数 ， 且 宿主 机 
的 resolv.conf 中 第 一 条 DNS 记录 地 址 不 为 127.0.0.1 和 127.0.1.1 ， 
则 Docker Daemon 会 为 容器 配置 宿主 机 的 DNS 地 址 。 


Docker 容 器 DNS 地 址 的 问题 ， 不 仅仅 存在 于 docker run 命 令 
中 ,Dockerfile 的 build 过 程 中 只 要 涉及 RUN 命 令 ， 就 也 有 可 能 牵扯 
到 DNS 问题 ， 故 不 论 是 局 动 Docker Daemon 时 的 -dns 参 数 还 是 启动 
Docker 容 希 时 的 -dns 参数 ， 均 不 可 小 靓 。 


12.4.2 Mount 


容 莫 的 运行 离 不 开 文件 系统 的 支持 ， 而 找到 容 颖 的 根 目 录 则 被 视 
为 一 项 基本 工作 。Docker 环 境 中 ， 容 元 的 文件 系统 概念 要 比 平 常 复杂 
一 些 。 文 件 系统 在 容器 看 来 是 一 个 树 型 结构 ， 但 是 对 于 福 主 机 疙 至 
Docker Daemon 而 言 却 并 非 如 此 。 


Mount( ) 艺 数 即 实现 获取 容 颖 的 根 目 录 ， 并 赋予 
containerbasefs , container.Mount( ) 的 实现 通过 daemon 的 
Mount 负 数 来 完成 ， 源 码 实 现 位 
于 ./docker/docker/daemon/daemon.go#L907-L919 , 如下: 

func (daemon *Daemon) Mount(container *Container) error { 
dir, err := daemon.driver.Get(container.ID, container.GetMountLabel()) 
if err != nil { 


return fmt.Errorf("Error getting container %s from driver %s: %s", 
container.ID, daemon.driver, err) 


if container.basefs == "" { 


container.basefs = dir 


} else if container.basefs != dir { 


return fmt.Errorf("Error: driver %s is returning inconsistent 
paths for container %s ('%s' then '%s')",daemon.driver, container.ID, 
container.basefs, dir) 


return nil 


12.4.3 InitiallzeNetworking 


级 数 intializeNetworking 的 作用 与 实现 在 7.4.2 节 中 分 析 过 。 总 
而 言 之 ,Docker Daemon 需 要 处 理 用 户 指定 的 网 络 模式 ( bridge、 
host、other container 和 none 模 式 中 的 一 种 ) ， 进 行 相应 的 网 络 配 
莹 与 初始 化 , 最终 将 所 有 初始 化 后 的 信息 都 存 入 container 对 象 中 。 


12.4.4 verifyDaemonSetting 


网 络 方面 的 配置 ,以 及 诸如 容器 内 存 、CPU 限 制 等 参数 ， 都 准备 
毕 之 后 ,， Docker Daemon 对 container 对 象 的 Config 属 性 进行 了 


二 全 


一 步 的 验证 ,查看 是 否 参 数值 与 Docker Daemon 的 运行 环境 出 现 


dl} 


岂 


不 一 致 的 情况 。 尔 数 verifyDaemonSetting 就 负责 这 样 的 工作 ，, 源 
码 实现 位 于 ./docker/docker/daemon/container.go#L936- 
L948 , 如 下 : 

func (container *Container) verifyDaemonSettings() { 


if container.Config.Memory > 0 && !container.daemon.sysInfo.MemoryLimit { 


log.Infof ("WARNING: Your kernel does not support memory Limit 
capabilities. Limitation discarded.") 


container.Config.Memory = 0 


if container.Config.Memory > 0 && !container,.daemon.sysInfo.SwapLimit { 


log.Infof ("WARNING: Your kernel does not support swap limit 
capabilities. Limitation discarded.") 


container.Config.MemorySwap = -1 


if container.daemon.sysInfo.IPv4ForwardingDisabled { 


log.Infof ("WARNING: IPv4 forwarding is disabled. Networking will not 
work") 


} 


从 代码 的 角度 可 见 ， 验 证 的 维度 主要 有 三 个 : 系统 内 核 是 否 支 持 
cgroup 内 存 限制 ， 系 统 内 核 是 否 支 持 cgroup 的 Swap 内 存 限制 ,以 及 
系统 内 核 是 否 支 持 网 络 接 口 间 IPv4 数 据 包 的 转发 。 首 先 需 要 明确 的 
是 : 如 何 判 断 系统 内 核 在 这 三 个 维度 上 是 否 支 持 。 对 于 cgroup 内 存 限 
制 和 和 swap 内 存 限 制 , Docker Daemon 在 局 动 时 即 会 前 往 cgroup 文 
件 系 统 的 挂 载 点 扫描 , 一旦 发 现 memory.limit_in_bytes 文 件 和 
memory.soft_limit_in_bytes 文 件 ， 则 说 明 系 统 内 核 支 持 cgroup 内 
存 限制 ; 同 理 ,一旦 发 现 memory.memsw.limit_in_bytes , 则 说 明 
系统 内 核 支 持 cgroup 的 Swap 内存 限制 。 原 则 上 ， Docker Daemon 
只 要 找到 文件 /proc/sys/net/ipv4/ip_forward ,就 可 以 认为 系统 内 核 
支持 IPv4 包 的 转发 功能 ， 然而 在 Docker 1.2.0 版 本 上 却 并 未 很 好 地 完 
善 这 一 点 


AAANO 


12.4.5 prepareVolumesForContainer 


volume 是 Docker 中 有 关 存 储 的 重要 概念 。 了 解 完 Docker 的 镜 
像 原 理 之 后 ， 也 许 很 多 人 都 会 认为 Docker 容 器 中 所 有 内 容 的 存储 都 会 
在 aufs 联 合 挂 载 的 文件 系统 中 。 当 然 ， 这 样 的 观点 是 不 够 准确 的 。 
Docker 人 允许 用 户 从 容 希 外 部 挂 载 目 录 人 至 容 硕 内 部 ， 这 一 方面 扩展 了 容 
需 文 件 系统 的 范畴 ， 另 一 方面 拓 友 了 容 需 与 外 界 共享 资源 的 方式 。 对 
于 单个 容 背 而 言 ， 用 户 可 以 为 其 配置 两 种 类 型 的 volume， 第 一 种 是 
bind-mount 类 型 的 volume , 即 用 户 指定 容 闫 外 部 目录 挂 载 到 容 闫 内 
部 的 指定 目录 ; 另 一 种 是 data volume , 即 用 户 只 指定 volume 在 容 
载 内 部 的 目录 ,关于 volume 在 宿主 机 上 的 目录 ,Docker Daemon 
接管 创建 工作 。 


volume 的 存在 使 得 Docker 容 益 的 存储 可 以 实现 持久 化 。 对 于 数 
据 存储 类 的 镜像 ， 如 MySQL、MongDB 等 ， 均 会 采用 data 
volume ,用 于 持久 化 数据 存储 。 以 MySQL 为 例 ， MySQL 存储 引擎 
会 将 数据 存储 在 文件 系统 的 /var/lib/docke 咀 录 下 ,而 此 目录 又 是 通 
过 data volume 的 形式 挂 载 进 容 右 的 ， 实 际 位 置 在 簿 主机 文件 系统 中 
位 于 /var/lib/docker/vfs/dir/<some id> ， 因 此 数据 将 会 存 入 宿主 
机 文件 系统 的 /var/lib/docker/vfs/dir/<some id> 中 。 更 为 重要 的 
是 , Docker Daemon 使 用 docker rm 命令 删除 容器 时 ， 如果 不 指定 - 


v 参 数 ， 则 默认 不 会 删除 容 郑 的 data volume , 即 目 
录 /var/lib/dockervfs/dir< some id> 。 长 此 以 往 ， 如 果 不 对 data 
volume 的 磁盘 空间 进行 清理 ， 很 容易 消耗 磁盘 空间 。 


级 数 prepareVolumesForContainer 的 作用 为 : 通过 用 户 指定 
的 volume 参 数 以 及 镜像 中 的 data volume 参 数 ， 为 容 厂 准备 更 为 具 
体 的 Volumes 信 息 。 在 Docker Daemon 中 ， 结构 体 Volume 的 定义 
如 下 : 


type Volume struct { 
HostPath string 
VolPath string 
Mode string 
isBindMount bool 


一 个 Volume 实 例 均 会 有 4 个 基本 属性 ，HostPath 代 表 volume 在 
宿主 机 上 的 路 径 ，VolPath 代 表 volume 在 容器 内 部 的 路 径 ，Mode 代 
表 容 器 对 于 Volume 的 读 写 权 限 ，isBindMount 代 表 volume 是 否 ; 


bind-mount 类 型 ， 


若 容 希 的 某 个 volume 属 于 bind-mount 类 型 ， 则 用 户 必须 显 式 指 
定 答 主机 上 的 路 径 HostPath、 容 莫 内 部 的 路 径 VolPath ， 以 及 想 要 的 
权限 。 如 果 volume 为 data volume , 则 data volume 的 规范 中 不 允 
许 用 户 指定 volume 在 宿主 机 上 的 路 径 ， 此 时 Docker Daemon 会 接 
管 volume 在 宿主 机 上 的 路 径 配置 。Docker Daemon 创 建 data 


vOolume 的 函数 为 createVolumeHostPath , 定义 位 
于 ./docker/docker/daemon/volumes.go#L222-L238 , 如下: 


func createVolumeHostPath(container *Container) (string, error) { 
volumesDriver := container.daemon.volumes.Driver() 
// Do not pass a container as the parameter for the volume creation. 
// The graph driver using the container's information ( Image ) to 
// create the parent. 


c, err := container.daemon.volumes.Create(nil, "", "", "", "", Nil, nil) 
if err != nil { 
return "", err 
hostPath, err := volumesDriver,.Get(c.ID, "") 
if err != nil { 


return hostPath, fmt.Errorf("Driver %s failed to get volume rootfs 
%5S: %s", volumesDriver, c.ID, err) 


return hostPath, nil 


Docker Daemon 通 过 类 型 为 vfs 的 graphdriver 来 管理 data 
volume , 由 于 containerdaemon.volumes 是 指向 graph.Graph 
的 指针 ， 故 Create 也 数 位 于 graph 包 中 ， 功 能 为 创建 一 个 镜像 ， 并 在 
volumes 这 个 graph 中 注册 ,最 终 通过 代码 volumesDriverGet 
( c.ID ,"") 返回 volume 在 宿主 机 上 的 路 径 ,路径 
为 /var/lib/docker/vfs/dir/< some id> /。 


级 数 prepareVolumesForContainer 完 成 的 是 mount 信 息 的 准 


备 工 作 ， 创 建 所 有 的 Volume 对 象 ， 并 存 入 container 对 象 中 。 


12.4.6 setupLinkedContainers 


容 载 间 的 link 操 作 人 允许 容 背 通 过 环境 变量 的 形式 发 现 另 一 个 容 
妖 ， 并 在 这 两 个 容 右 间 安 全 传输 信息 。 用 户 在 启动 容 姻 时 可 以 通过 设 
置 --link 参 数 来 完成 这 项 工作 ,如 docker run--link db : 
aliasubuntu : 14.04， 作 用 是 启动 容器 时 为 容器 db 设置 一 个 别名 
alias， 并 将 别名 alias 以 及 容 右 db 的 网 络 信息 配置 到 新 局 动容 需 的 环 
境 变量 中 。 


级 数 setupLinkedContainers 的 作用 就 是 为 后 动容 器 配置 link 的 
环境 变量 。 该 曙 数 的 的 执行 流程 图 如 图 12-4 所 示 。 


下 面 对 于 图 12-4 中 各 个 步骤 的 作用 进行 简单 摘 述 。 


步骤 1， 获 取 指 定 容 闫 的 子 容 闫 ， 实 现代 码 为 children , err : 
=daemon.Children( container.Name) 。Docker 创 建 的 容器 被 
daemon 管 理 时 并 非 与 其 他 容 需 富 无 关系 。 一 旦 容器 存在 link 信 息 ， 
Docker Daemon 对 于 容器 的 “父子 关系 ”就 会 充分 体现 出 来 。 被 链接 
的 容 闫 将 会 被 视 为 发 起 链接 的 容 希 的 子 容器 。 而 这 样 的 关系 将 会 记录 
在 Docker Daemon 管 理 的 graphdb 中 。 关 于 Docker Daemon 如 何 
并 且 何 时 记录 这 样 的 和 关系， 实际 位 于 container Start( ) 的 
RegisterLinks 中 ， 有 兴趣 的 读者 可 以 继续 深入 研读 Docker 关 于 


graphdb 的 容 怖 link 信 息 记 录 。 因 此 ， 步 又 1 会 从 graphdb 中 获取 所 
需 局 动容 妖 的 所 有 子 容 背 ， 目 的 是 为 了 将 所 有 子 容 希 的 网 络 信息 配置 
进 此 容 肴 的 环境 变量 。 










他 》 


get _ container S children 
for child in children 


link := links. Newlink() 


make iptables through 


link. ToEnv () 


12-4 setupLinkedContainers 函 数 执行 流程 图 





完成 步骤 1 之 后 ,Docker Daemon 随即 通过 children 中 的 每 一 
个 child 进 行 link 信 息 Env 化 。 本 节 暂 且 分 析 流程 中 的 第 一 个 循环 。 


步 又 2 ,创建 完备 的 link 对 象 ， 对 象 中 包含 link 所 需要 的 所 有 信 
息 ,如 : 父 容器 的 IP、 子 容器 的 IP、 子 容器 被 链接 时 的 别名 、 子 容器 
Config 信 息 中 的 Env 属 性 以 及 子 容 莫 内 部 暴露 的 端口 号。 创建 link 对 
象 的 实现 源码 位 于 ./docker/docker/daemon/container.go#L977- 


L983 , 如 下 : 


link, err := links.NewLink( 
container.NetworkSettings.IPAddress, 

child.NetworkSettings.IPAddress, 

LinkALias， 

child.Config.Env, 

child.Config.ExposedPorts, 

daemon .eng) 


步骤 3， 使 得 link 对 象 的 实际 意义 生效 ， 开 局 link 容 硕 间 访问 的 
iptables 规 则 。link.Enable( ) 的 实现 位 
于 ./dockerdockerlinks/link.go ,实现 手段 为 创建 并 执行 名 
为 “link" 的 job，, 传 入 的 参数 大 多 为 link 对 象 的 内 容 。Docker 
Daemon 有 局 动 时 ,执行 网 络 初 始 化 时 , 曾 注册 了 key 为 “link" 的 处 理 
方法 ,其 中 value 为 “LinkContainers"。 国 数 LinkContainer 的 内 容 
较为 易 懂 ,主要 是 通过 链接 两 个 容 怖 的 网 络 信 息 ， 保 证 即使 在 - 
icc= false 的 情况 ， 依 | 日 可 以 通过 开启 iptables 规 则 ,保证 容器 间 指 
定 剖 口 的 访问 保持 畅通 。 这 样 的 iptables 规 则 主要 有 以 下 两 条 : 
iptabLes ,Raw(action， "FORWARD", 
"-i", bridgeIlface, "-o", bridgelface, 
", proto, 
", parentIP, 
"--dport", port, 


p 

S 
"-d", childIP, 
1 j", "ACCEPT") 


第 一 条 规则 用 于 接受 父 容器 到 子 容器 指定 端口 的 连接 ， 其 中 也 指 
定 了 协议 类 型 ， 并且 表明 是 容 棵 间 的 通信 ，, 理由 是 从 bridgelface 
( docker0) 发 出 ,从 bridgelface( docker0) 接收 。 


iptables. Raw(action， ”FORWARD ， 


"-1"，bridgeIface，"-0"，bridgeIface， 
"-p", proto, 

"-s", ChildIP, 

"--Ssport", port, 

"-d", parentIP, 

"-j", "ACCEPT") 


第 二 条 规则 用 于 接受 子 容 兹 的 指定 端口 到 父 容 问 的 连接 ， 其 中 也 
指定 了 协议 类 型 ， 并 且 表 明 是 容 右 间 的 通信 ,原因 与 前 面 一 致 。 


步 又 4 , 将 link 对 象 Env 化 ,只 有 最 终 的 Env 人 信息， 才能 被 容 妖 内 
部 的 进程 使 用 。 实 现 源码 为 link.ToEnv( ) ，ToEnv 上 级 数 的 定义 位 
于 ./docker/docker/links/links.go#L50 , 而 link 对 象 Env 化 的 主要 


源码 如 下 : 


if p := l.getDefaultPort(); p != nil { 
env = append(env, fmt.Sprintf("%s PORT=%s://%s:%s", alias, p.Proto(), 
Ll.ChildIP, p.Port())) 


// Load exposed ports into the environment 
for ，p := range l.Ports { 
env = append(env, fmt.Sprintf("%s PORT %s %s=%s://%s:%s", alias, 
p.Port(), strings.ToUpper(p.Proto()), p.Proto(), 
Ll.ChildIP, p.Port())) 
env = append(env, fmt.Sprintf("%s PORT %s %s ADDR=%s", alias, 
p.Port(), strings.ToUpper(p.Proto()), .ChildIP)) 
env = append(env, fmt.Sprintf("%s PORT %s %s PORT=%s", alias, 
p.Port(), strings.ToUpper(p.Proto()), p.Port())) 
env = append(env, fmt.Sprintf("%s PORT %s %s PROTO=%s", alias, 
p.Port(), strings.ToUpper(p.Proto()), p.Proto())) 


} 
// Load the linked container's name into the environment 
env = append(env, fmt.Sprintf("%s NAME=%s", alias, \.Name)) 


以 上 源码 也 就 是 在 父 容 希 中 出 现 诸多 以 下 环境 变量 的 原因 。 父 容 
莫 中 关于 子 容 莫 link 信 息 的 样 例 环境 变量 如 下 : 


DB NAME=/web/db 

DB PORT=tcp://172.17.0.33:3456 

DB PORT 3456 TCP=tcp://172.17.0.33:3456 
DB PORT 3456 TCP PROTO= tcp 

DB PORT 3456 TCP PORT=3456 

DB PORT 3456 TCP ADDR=172.17.0.33 











众多 如 以 上 形式 的 env 创 建 之 后 ,Docker Daemon 会 完成 所 有 
link 环 境 变量 的 拼接 ,在 setupLinkedContainers 函 数 返回 内 容 时 返 
回 env， 最 终 赋 值 给 Start 强 数 中 的 linkedEnv。 


12.4.7 setupWorkingDirectory 


Docker 容 颖 运行 时 ,当前 工作 目录 并 非 根 目录 ， 用户 完全 可 以 通 
过 传 入 --workdir 参 数 来 设置 容 莫 运行 时 的 当前 工作 目录 ， 这 部 分 工作 
由 也 数 setupWorkingDirectory 来 完成 。 对 于 用 户 指定 的 workdir ， 
Docker Daemon 首 先 查 找 此 路 径 是 否 存 在 ，, 若 存 在 且 是 目录 ， 则 表 
明 workdir 有 效 ; 否则 ,Docker Daemon 现 场 创建 相应 的 目录 ,并 
对 目录 添加 文件 权限 。 


12.4.8 createDaemonEnvironment 


Docker 容 器 的 运行 环境 有 很 多 部 分 组 成 ， 有 通过 命名 空间 实现 的 
隅 离 环 境 ， 有 通过 控制 组 实现 的 资源 空间 环境 ， 也 有 用 户 配置 环境 变 
量 的 运行 环境 等 。 函 数 createDaemonEnvironment 则 为 Docker 容 
喜 的 运行 创建 相应 的 环境 变量 ,这样 的 环境 变量 不 仅 包括 系统 为 容 尼 

添加 的 环境 变量 ， 还 包括 用 户 为 容 希 指定 或 生成 的 环境 变量 。 


疯 数 createDaemonEnvironment 的 源码 实现 位 
于 ./docker/docker/daemon/container.go#L1004-L1024 , 如 


下 : 


func (container *Container) createDaemonEnvironment(linkedEnv []string) []string 


// Setup environment 
env := []stringt{ 


"PATH=" + DefaultPathEnv, "HOSTNAME=" + container.Config,.Hostname, // 
Note: we don't set HOME here because it'LL get autoset intelligently // based on 
the value of USER inside dockerinit, but only if it isn't // set already (ie, 
that can be overridden by setting HOME Via -e or ENV 


// in a Dockerfile). 


if container.Config.Tty { 
env = append(env, "TERM=xterm") } 


env = append(env, linkedEnv...) // because the env on the container can 
override certain default values // we need to replace the 'env' keys where they 
match and append anything // else. 


env = utils.ReplaceOrAppendEnvValues(env, container.Config.Env) return env 


从 清晰 的 代码 中 ， 我 们 可 以 辨别 出 env 对 象 为 一 个 string 型 数 
组 ,数组 中 的 每 一 项 均 为 Docker 容 器 的 环境 变量 。 代 码 表明 ,这样 的 
环境 变量 有 PATH、HOSTNAME、TERM 以 及 用 户 指定 容器 link 之 后 
产生 的 环境 变量 。 所 有 的 环境 变量 会 在 运行 容器 进程 时 ， 加 载 到 进程 
的 环境 变量 中 。 


12.4.9 populateCommand 


容 莫 需要 运行 ， 自然 离 不 开 容 右 运 行 的 入 口 ， 即 通过 运行 程序 达 
到 容 莫 运行 的 目 的 。 为 此 ，Docker Daemon 以 Command 的 形式 提 
供 容 右 的 运行 人口， 并 通过 哨 数 populateCommand 填 充 
Command 的 内 容 。 


第 7 章 对 populateCommand 的 实现 有 详尽 的 介绍 ， 其 中 较为 重 
要 的 依然 是 Command 的 类 型 以 及 与 其 他 数据 结构 的 关系 。 


Docker Daemon 有 局 动容 闫 的 多 个 阶段 都 对 container 对 象 的 
Config 属 性 进行 配置 和 处 理 ， 而 最 终 这 些 变化 都 会 体现 在 Command 
对 象 实例 中 ， 如 initializeNetworking 完 成 的 网 络 配置 将 修改 
command 对 象 中 的 网 络 部 分 , prepareVolumesForContainer 完 
成 的 volume 配 置 也 会 在 setupMountsForContainer 绚 数 执行 过 程 
中 配置 进 Command( _ volume 转换 为 mount 对 象 ) 
setupWorkingDirectory 则 设置 Command 对 象 中 的 容器 进程 工作 
目录 等 。 


容 居 运行 的 入 口 已 经 配置 完毕 , Docker Daemon 启 动容 器 也 将 
一 和 触 即 发 。 


12.4.10 setupMountsForContainer 


级 数 prepareVolumesForContainer 的 使 命 是 : 将 用 户 在 
volume 接 口 配置 的 volume 转 换 为 Docker Daemon 能 识别 的 
volume 类 型 ; 而 setupMountsForContainer 的 作用 是 : 将 Docker 
Daemon 中 所 有 需要 从 容 希 外 挂 载 到 容 居 内 的 目录 ， 转 换 为 
execdriver 可 以 识别 的 Mount 类 型 。 也 数 
setupMountsForContainer 的 源码 实现 位 
于 ./docker/docker/daemon/volume.go#L51-L75 , 如 下 : 


func setupMountsForContainer(container *Container) error { 
mounts := []execdriver.Mount{ 
{container.ResolvConfPath, "/etc/resolv.conf", true, true}, } 


if container.HostnamePath != "" { 


mounts = append(mounts, execdriver.Mount{container.HostnamePath, 
"/etc/hostname", true, true}) } 


if container.HostsPath != "" { 


mounts = append(mounts, execdriver.Mount{container.HostsPath, 
"/etc/hosts", true, true}) } 


// Mount user specified volumes // Note, these are not private because you 
may want propagation of (un)mounts from host // volumes. For instance if you use 


-V /usr:/usr and the host Later mounts /usr/share you // want this new mount in 
the container for r, v := range container.Volumes { 


mounts = append(mounts, execdriver.Mount{v, r, 
container.VolumesRW[r], false}) } 


container.command ,Mounts = mounts return nil 


以 上 代码 中 , mounts 为 execdriverMount 类 型 的 数组 ， 数 组 的 
内 容 均 表 示 容 妖 内 部 的 路 径 与 宿主 机 路 径 的 挂 载 映射 关系 ， 并 标明 读 
写 权 限 与 私有 权限 。 容 怖 内 部 的 挂 载 点 一 般 包 
括 /etc/resolv.conf、/etc/hostname、/etc/hosts 以 及 所 有 的 
volume 等 。 最 终 ，mounts 对 象 赋 子 container.command 的 


Mounts 属 性 ,为 Command 类 型 实例 服务 。 


12.4.11 waitForStart 


Docker Daemon 为 启动 容 右 所 做 的 准备 工作 不 可 请 不 充分 。 准 
备 工作 全 部 完成 之 时 ， 也 是 启 动容 莫 、 运 行 容 莫 之 时 。 函 数 
waitForStart 的 功能 就 是 局 动容 颖 进程 ， 并 根据 用 户 指定 的 重启 策略 

应 对 容器 启动 失败 的 情况 。 


疯 数 waitForStart 的 定义 位 
于 ./docker/docker/daemon/container.go#L1070-L1082 ,如 
下 : 


func (container *Container) waitForStart() error { 
container.monitor = newContainerMonitor(container， 
container.hostConfig.RestartPolicy) 
// block until we either receive an error from the initial start of the 
container's 
// process or until the process is running in the container 
select { 
case <-container.monitor.startSignal: 
case err := <-utils.Go(container.monitor.Start): 
return err 


return nil 


Docker Daemon 为 container 创 建 了 一 个 containerMonitor 类 
型 实例 ， 并 将 其 赋予 container 对 象 的 monitor 属 性 。 类 型 
containerMonitor 的 定义 位 
于 ./docker/docker/daemon/monitor.go ,在 启动 容器 时 起 到 监控 


容器 主 进程 的 角色 。 如 果 Docker 用 户 为 容器 的 启动 配置 了 重启 策略 ， 
则 containerMonitor 会 确保 主 进 程 启动 失败 时 基于 重启 策略 而 重 
启 。 然 而 ， 若 容 莫 由 于 某 种 原因 在 重启 策略 下 依旧 重启 失败 ,， 则 
containerMonitor 将 重 置 以 及 清理 container 对 象 占据 的 资源 ， 如 为 
容 蓝 分 配 的 网 络 资源 、 为 容 右 创建 的 rootfs 等 。 


理解 containerMonitor 的 监控 作用 之 后 ， 还 需要 关注 其 局 动容 
厂 的 本 质 ， 源 代码 为 container.monitor.Start。Start 郧 数 的 作用 很 
明显 ， 即 通过 启动 populateCommand 函 数 创建 的 Command 对 
象 ， 完 成 容 希 的 创建 。 原 理 如 此 ， 而 实现 却 要 更 复杂 一 些 ， 代 码 的 执 
行 流 首先 会 进入 execdriver( native) ，, execdriver 为 了 适 配 
libcontainer 的 接口 ， 需 要 根据 container 中 的 Command 对 象 创建 
libcontainer 的 Config 对 象 ， 最 终 通过 |libcontainer 中 的 


Fe 口 口 


namespaces 包 来 实现 容 需 的 局 动 。 


创建 容器 对 象 ， 仅 仅 是 为 Docker 容 器 组 织 了 必需 的 配置 信息 ， 并 
未 将 配置 信息 落实 至 Docker 容 需 运 行 环境 中 的 具体 资源 与 能 力 。 
此 ,libcontainer 在 局 动容 希 时 ， 一 方面 为 容 硕 初始 化 具体 的 物理 资 
源 并 提供 相应 的 容 颖 能 力 ， 另 一 方面 启动 容 莫 的 主 进 程 。 第 13 章 将 分 
析 Docker 容 器 主 进程 dockerinit 以 及 其 他 相关 内 容 。 


12.5 总 结 


Docker 容 希 的 启动， 意味 着 用 户 运 行 时 的 开始 。 对 于 Docker 用 
户 而 言 ， 仪 仅 能 感受 到 自身 应 用 的 正常 运行 。 然 而 ， 对 于 Docker 
Daemon 而 言 , 需要 完成 的 工作 要 和 远 比 这 复杂 ， 从 最 初 的 镜像 查找 ， 
到 rootfs 配 备 ， 还 有 网 络 、volume、 容 硕 link 等 配置 信息 的 收集 ,以 
及 最 后 启动 代表 容器 主 进程 的 Command 命 令 。 


Docker 体 系 内 的 万 干 概念 ， 最 后 都 融 汇 在 代表 容器 主 进程 的 
Command 命 令 中 ， 且 最 终 体 现在 主 进 程 的 局 动 流程 中 。 本 章 从 
Docker 容 器 的 创建 入 手 ， 着重 分 析 了 Docker Daemon 的 启动 全 过 
程 。 


第 13 章 ”dockerinit 启 动 


13.1 引言 


Docker 容 器 作为 Docker Daemon 管 理 的 对 象 ， 给 用 户 的 体验 
是 一 个 隔离 性 较 好 的 运行 环境 。 作 为 容 闫 技术 ， 隔离 环 境 背 后 的 技术 
支撑 是 什么 ? Docker 容 器 可 以 运行 用 户 应 用 进程 ， 容 元 与 进程 的 关系 
又 如 何 ? 可 以 说 ， 认识 Docker 是 一 条 漫长 的 路 ， 在 这 条 路 上 ， 仍 然 存 
在 不 少 疑 惑 。 


为 阐述 Docker 容 莫 与 进程 的 关系 ， 首 先 以 用 户 都 见 过 的 docker 
run 命 令 为 例 。 通 过 Docker 容 郑 完 成 指定 应 用 进程 的 运行 ， 相 信和 所 有 
的 Docker 用 户 都 不 卫生， 然而， 应 用 进程 是 个 是 容 背 内 的 第 一 个 进 
程 ,一旦 提 及 这 一 点 ， 也 会 激 起 Docker 用 户 心中 的 疑惑 。 虽 然 第 7 章 
已 经 对 容 郑 与 进程 的 关系 进行 了 初步 的 介绍 与 分 析 ,但 是 关于 容 需 内 
第 一 个 进程 究竟 为 何方 神圣 ， 依 然 没 有 揭 开 神秘 的 面纱 。 开 门 见 山 ， 
Docker Daemon 局 动 Docker 容 背 时 ， 运行 的 第 一 个 进程 并 不 是 用 
户 的 应 用 进程 ， 而 是 一 个 称 为 dockerinit 的 进程 。 


本 章 主 要 从 源码 的 角度 介绍 dockerinit， 并 分 析 dockerinit 启 动 
流程 的 实现 。 本 书 基于 Docker 1.2.0 版 本 ,libcontainer 的 版 本 为 


1.2.0。 本 章 内 容 主 要 包含 以 下 4 个 方面 : 


1) 简要 介绍 dockerinit ; 
2) 分 析 dockerinit 的 执行 入 口 ; 
3) 分 析 dockerinit 的 运行 ; 


4) 分 析 libcontainer 的 运行 。 


13.2 dockerinit 介 绍 


正如 其 名 ， 可 以 认为 dockerinit 是 Docker 容 器 中 的 init 进 程 。 
Linux 操 作 系统 中 ，init 进 程 是 一 个 非常 重要 的 进程 ， 它 负责 初始 化 系 
统 ， 并 且 是 所 有 用 户 进程 的 祖先 进程 。 相 同 的 概念 ， 在 Docker 容 厂 中 
也 有 很 好 的 体现 ，dockerinit 作 为 Docker 容 器 中 的 第 一 个 进程 ， 同样 
扮演 初始 化 容器 的 角色 ， 同 样 是 Docker 容 器 内 所 有 进程 的 祖先 进程 。 


13.2.1 dockerinit 初 始 化 内 容 


既然 dockerinit 扮 演 初 始 化 容器 的 角色 ， 那么 具体 初始 化 容器 的 
哪些 内 容 必 将 受到 关注 。 对 于 Docker 容 器 而 言 ， 容器 的 资源 以 及 容器 
的 能 力 是 重点 ， 而 分 配 的 资源 以 及 授予 的 能 力 ， 都 应 该 在 容器 创建 时 
初始 化 。 以 下 是 dockerinit 初 始 化 的 部 分 资源 与 能 力 : 


网 络 资源 。Docker Daemon 为 bridge( 桥接 ) 模式 下 的 容 冀 
创建 网 络 命名 空间 ,创建 初期 命名 空间 内 并 无 网 络 栈 ( 如 网 络 接口 
等 ) ，dockerinit 需 要 为 容 闫 初始 化 网 络 命名 空间 ,配置 独立 的 网 络 
栈 ; 

' 挂 载 资源 。 容 希 都 有 独立 的 mount namespace， 初始 化 挂 载 
资源 包括 设置 容 希 内 部 的 设备 、 挂 载 点 以 及 文件 系统 等 ; 


用 户 设置 。 容 器 都 属于 一 个 用 户 ，dockerinit 负 责 为 容器 设置 组 
( group) 、 组 ID( GID) 与 用 户 ID( UID) 

:环境 变量 。 容 器 中 的 环境 变量 使 得 容 希 内 进程 拥有 更 多 的 运行 参 
数 。 


容器 Capability。 容 右 中 用 户 使 用 的 内 核 与 从 主机 无 差别 ， 
Linux 的 Capability 机 制 则 可 以 确保 容 颖 内 进程 以 及 文件 的 


Capability 得 到 限制 。 


13.2.2 dockerinit 与 Docker Daemon 


dockerinit 是 Docker 容 背 中 的 第 一 个 进程 。Linux 操 作 系 统 中 ， 
进程 的 诞生 往往 都 由 fork 系 统 调用 产生 ，dockerinitj 井 程 自然 也 不 会 
例外 。 如 此 说 来 ,dockerinit 的 父 进程 最 有 可 能 是 Docker 
Daemon， 现 实情 况 的 确 如 此 。 


父子 关系 是 Docker Daemon 与 dockerinit 之 间 最 明了 的 关系 。 
Docker Daemon 完 成 进程 fork 之 后 ,Docker Daemon 是 父 进程 ， 
dockerinit 是 子 进程 ; 而 exec 子 进程 则 完成 容 肴 的 初始 化 工作 。 关 于 
容 冀 的 初始 化 工作 ， 需 要 清楚 的 是 dockerinit 的 初始 化 依据 来 源 于 何 
处 ， 例 如 ,dockerinit 需 要 初始 化 网 络 栈 ， 在 自身 网 络 命名 空间 中 创 
建 独立 的 网 络 设备 ， 那 网 络 设备 的 配置 信息 从 何 而 来 ?虽然 新 建 了 
mount 命 名 空间 , 但 是 命名 空间 的 挂 载 点 位 于 何 处 ? 进程 dockerinit 
仍然 需要 足够 的 依据 ， 保 证 初始 化 工作 的 顺利 进行 。 


既然 是 父子 关系 ，dockerinit 被 派生 出 来 时 ，Docker Daemon 
即 可 以 将 众多 的 配置 信息 通过 很 多 有 效 的 途径 传递 至 dqockerinit。 为 
了 使 得 dockerinit 得 到 配置 信息 ，Docker Daemon 将 容器 所 有 的 
Config 配 置 先 json 化 之 后 ， 存 入 本 地 文件 系统 中 ,而 dockerinit 在 初 


始 化 mount 命 令 空 间 前 ， 提 取 这 部 分 信息 。 另 外 , Docker Daemon 


为 dockerinit 传 递 命 令 参数 也 是 一 种 简单 的 方式 。 


13.3 dockerinit 执 行人 入口 


第 12 章 主要 分 析 Docker 容 器 的 创建 ， 然 而， 关于 Docker 
Daemon 启 动容 器 ， 分 析 到 创建 monitor 对 象 并 监控 容器 的 启动 之 
后 , 却 并 未 再 深入 。 若 继续 深究 ,我们 则 可 以 发 现 程 序 的 执行 将 从 


Docker Daemon 转 移 至 execdriver , 最 终 进 入 libcontainer。 


寻找 dockerinit 的 证 生 ， 必 须 追 六 到 execdriver。Docker 

Daemon 启 动容 器 的 参数 ， 最 终 需 要 libcontainer 来 加 载 , 而 
execdriver 负 责 将 Docker Daemon 描 述 容 器 的 container 对 象 转 
义 ， 使 其 符合 libcontainer 的 接口 。 在 这 样 的 过 程 中 ，execdriver 调 
用 libcontainer 的 namespace 包 时 ,将 dockerinit 作 为 参数 传递 至 
libcontainer。 调 用 员 数 的 定义 位 于 libcontainer 项 目的 
namespace 包 中 ， 国 数 名 为 exec， 源码 实 现 位 
于 ./docker/libcontainer/namespaces/exec.go#L24 ,如 下 : 

func Exec(container *libcontainer.Config, stdin io.Reader, stdout, stderr 


io.Writer, console string, rootfs, dataPath string, args []string, createCommand 
CreateCommand, startCallback func()) (int, error) 


13.3.1 createCommand 分 析 


浙 数 exec 传 入 的 众多 参数 中 ， 与 dockerinit 相 关 的 是 形 参 
createCommand , 而 execdrivenl 周 用 namespaces.exec( ) 限 数 


时 ， 实 参 如 下 : 


func(container *libcontainer.Config, console, rootfs, dataPath, init string, child 
*os.File, args []string) *exec.Cmd { 
c.Path = d.initPath 
c.Args = append([]string{ 
DriverName， 
"-console", console, 
"-pipe", "3", 
"-root", filepath.Join(d.root, c.ID), 


}:; args..') 
// set this to nil so that when we set the clone flags anything else is reset 
c.SysProcAttr = &syscall.SysProcAttrt{ 

Cloneflags: uintptr(namespaces.GetNamespaceFlags(container.Namespaces)), 


} 

c.ExtraFiles = []*os.File{child} 
c.Env = container.Env 

c.Dir = c.Rootfs 

return &c.Cmd 


可 见 ， 传 入 的 实 参 为 一 个 函数 ， 此 也 数 的 作用 是 : 使 得 
libcontainer 执 行 namespaces.exec( ) 时 通过 该 函数 创建 一 个 
exec.Cmd 对 象 ， 以 便 libcontainer 直 接 通 过 Start 印 数 ， 启 动 该 
exec.Cmd 对 象 。 下 面 分 析 exec.Cmd 类 型 实例 c 的 各 属性 。 


.C.Path。 对 于 类 型 exec.Cmd 而 言 ， 唯 一 不 能 为 空 的 就 是 Path 参 
数 , 它 代表 执行 命令 所 在 路 径 , 而 d.initPath 的 值 即 为 Path 路 径 。 若 
Docker 的 版 本 为 1.2.0 , execdriver 的 类 型 为 native ,那么 默认 情况 


下 ，d.initPath 的 值 为 /var/lib/docker/init/dockerinit-1.2.0，, 
此 ,Docker Daemon 启 动 Docker 容 器 时 ， 均 会 执行 该 路 径 下 的 


dockerinit-1.2.0, 


.C.Args。 执 行 命令 的 参数 同样 重要 ，.c.Args 即 代表 dockerinit- 


1.2.0 命 令 的 执行 参 


1 所 示 。 


ES 


DriverName 


- console 
console 
-pipe 

3 

-Toot 


filepath.Join(d.root. c.ID) 





数 。 其 中 .c.Args 是 一 个 string 数 组 ， 内容 如 表 13- 


表 13-1 .c.Args 参 数 的 内 容 


代表 execdriver 的 具体 类 型 ， 默 认 情 况 下 值 为 “ native”， 此 参数 会 在 dockerinit 
执行 reexec.InitO 时 使 用 到 

名 为 “console” 的 flag, 值 为 紧 接 其 后 的 元 素 

console (pty slave) 的 路 径 

名 为 “pipe ”的 flag， 代 表 同 步 管道 的 文件 描述 符 fd 

名 为 “pipe ”的 flag 的 值 ， 代 表 同 步 管道 的 fd 值 为 3 

名 为 “root” 的 flag， 代 表 容 器 配置 文件 所 在 的 路 径 

名 为 “root” 的 flag 的 值 ， 一 般 为 /var/lib/docker/execdriver/native/<c.ID>， 该 路 
径 下 存放 着 文件 containerjson 和 statejson， 前 者 存储 容器 配置 对 象 Config 的 json 
信息 ; 后 者 存储 容器 的 init 进程 信息 、 网 络 信息 以 及 控制 组 路 径 等 

用 户 指 定 的 命令 ,包含 ENTRYPOINT 与 CMD， 在 dockerinit 执行 的 后 期 阶段 扮 
演 重要 角色 ， 实 现 系统 初始 化 工作 转变 为 用 户 进 程 的 运行 


.C.SysProcAttr。SysProcAttr 将 携带 exec.Cmd 运 行 的 操作 系统 
参数 ， 如 在 启动 dockerinit 时 ， 代 表 是 否 需 要 为 进程 创建 新 
namespace 的 参数 Cloneflags。 关 于 namespace 的 Cloneflags 共 


有 6 个 ， 分别 是 syscall.CLONE_NEWNS、 


syscall.CLONE NEWUTS、 syscall.CLONE NEWIPC. 


syscall.CLONE NEWUSER、 syscall.CLONE NEWPID 和 和 


syscall.CLONE_NEWNET， 而 默认 情况 下 Docker 1.2.0 并 未 完全 文 
持 用 户 命名 空间 ， 故 没有 使 用 syscall.CLONE_NEWUSER.。 


.C.ExtraFiles。ExtraFiles 将 携带 从 父 进 程 Docker Daemon 继 
承 的 文件 描述 符 ， 由 于 不 包括 标准 输入 ( 文件 描述 符 为 0) 、 标 准 输出 
( 文件 描述 符 为 1) 和 标准 错误 ( 文件 描述 符 为 2) ， 故 ExtraFile 的 值 
都 是 不 小 于 3 的 文件 描述 符 。 由 于 在 dockerinit 的 运行 初期 仍然 需要 与 
之 通信 , 故 Docker Daemon 创 建 了 一 个 管道 ， 并 将 管道 的 一 端 交 给 


dockerinit, 


.C,.Env。Env 用 于 指定 dockerinit 进 程 运 行 时 的 环境 变量 。 故 用 户 
运行 docker run 命 令 时 通过 -e 设 定 的 ENV 参 数 或 者 Dockerfile 中 的 
ENV 参 数 ， 都 会 在 此 时 用 来 设 定 dockerinit 进 程 的 环境 变量 。 


.C.Dir。Dir 用 于 指定 命令 exec.Cmd 的 工作 目录 ， 具 体 的 值 为 


execdriverCommand 的 rootfs。 


13.3.2 namespace.exec 


有 了 createCommand 的 基础 ,理解 libcontainer 中 的 
namespace.Exec 就 变 得 简单 很 多 。namespace.Exec 的 作用 无 非 
是 通过 createCommand 国 数 ， 创建 一 个 容器 启动 命令 exec.Cmd ， 
随后 局 动 该 命令 完成 dockerinit 进 程 的 运行 工作 。 容 痪 命令 局 动 的 源 
码 实现 位 于 ./docker/libcontainer/namespaces/exec.g0o#L24- 
L47 , 如下: 


func Exec(container *libcontainer.Config, stdin io.Reader, stdout, stderr 
io.Writer, console string, rootfs, dataPath string, args []string, createCommand 
CreateCommand, startCallback func()) (int, error) { 
var ( 
err error 
) 


// create a pipe so that we can syncronize with the namespaced process and 
// pass the veth name to the child 
syncPipe, err := Syncpipe.NewSyncPipe() 
if err != nil { 
return -1, err 
} 


defer syncPipe.Close() 
command := createCommand(container, console, rootfs, dataPath, 
os.Args[0], syncPipe.Child(), args) 
command.Stdin = stdin 
command.Stdout = stdout 
command.Stderr = stderr 
if err := command.Start(); err != nil { 
return -1, err 


} 
if err := command.Wait(); err != nil { 
if , ok := err.(*exec.ExitError); !ok { 
return -1, err 
} 
} 


以 上 代码 为 仅仅 是 namespace.Exec 纹 数 执行 的 前 面 一 部 分 ， 代 
码 结 构 较 为 清晰 ， 总 体 分 为 三 个 部 分 : 创建 syncPipe、 创 建 容 匡 命令 
以 及 容器 命令 的 局 动 。 


顾名思义 ， a 使 得 Docker Daemon 与 
dockerinit 可 以 通过 管道 的 形式 同步 资产 。 由 于 一 旦 dockeriniti 井 程 
局 动 ,dockerinit 进 程 的 运行 就 处 于 多 个 全 新 的 namespace 内 ,此 
时 Docker Daemon 与 dockerinit 处 于 相互 隔离 的 namespace 中 ， 
两 者 的 通信 变 得 不 便 ( 虽然 dockerinit 处 于 全 新 的 网 络 命名 空间 下 ， 
但 网 络 命名 空间 下 网 络 枝 仍 未 初始 化 ， 没 有 网 络 接口 用 于 通信 ) ， 故 
Docker 米 用 更 为 底层 的 管道 机 制 完成 操作 系统 上 分 别处 于 不 同 
namespace 进 程 的 通信 。syncPipe 主 要 用 于 Docker Daemon 向 
dockerinit 传 递 容 问 信 息 ， 如 容 右 内 网 络 设备 的 信息 等 。 


创建 容 莫 命令 即 为 createCommand 唤 数 的 实现 ,前面 已 经 涉 
及 ， 并 对 最 终 返 回 的 exec.Cmd 类 型 实例 进行 详细 分 析 。 总 而 言 之 ， 
createCommand 哨 数 为 容器 创建 了 静态 的 执行 入 口 。 


容器 命令 的 启动 通过 command.Start( ) 实现 。Start 负 数 负 
局 动 指定 的 命令 command , 但 是 不 对 该 命令 的 运行 执行 Wait 操 作 ， 
Wait 操 作 有 专门 的 Wait 约 数 来 完成 。 由 于 command 的 Path 参 数 为 
d.initPath , 即 /varlib/dockervinit/dockerinit-1.2.0 , 故 


libcontainer 会 启动 dockerinit-1.2.0 命 令 ， 换言之, dockerinit 的 
执行 被 触发 。 


分 析 至 此 ， 我 们 已 经 找到 dockerinit 的 执行 入 口 ， 但 这 并 不 意味 
着 Docker Daemon 会 将 所 有 执行 权 交 给 dockerinit ,Docker 
Daemon 关 于 容 怖 的 局 动 还 远 没 有 结束 。 局 动 dockerinit 之 后 ， 
Docker Daemon 与 dockerinit 的 执行 将 并 发 执行 ， 两 者 之 间 通 过 管 
道 的 形式 进行 同步 ,同步 完 成 之 后 ,Docker Daemon 与 dockerinit 
各 自 运行 ， 除 父子 关系 之 外 ,无 更 多 逻辑 关系 。13.4 节 将 深入 分 析 
dockerinit 的 执行 以 及 dockerinit 与 Docker Daemon 的 协同 通信 。 


13.4 dockerinit 云 行 


dockerinit 作 为 Docker 容 闫 中 运行 的 第 一 个 进程 ， 本质 上 , 它 是 
一 个 使 用 go 语言 编译 的 可 执行 文件 , 即 dockerinit-1.2.0。 既 然 如 
此 , 回 到 dockerinit 的 实现 函数 ， 可 以 发 现 dockerinit 的 实现 全 部 依 
靠 reexec.Init( ) 蚁 数 。dockerinit 的 main 约 数位 
于 ./docker/docker/dockerinit/dockernit.go#L9-L12 , 如下: 


func main() { 
// Running in init mode 
reexec.Init() 


} 


以 上 代码 简洁 得 有 点 极致 ,main 通过 reexec.Init( ) 来 实现 。 
是 否 reexec.Init( ) 真 的 实现 了 对 容器 环境 的 初始 化 ? 让 我 们 带 着 疑 
惑 进入 reexec.Init( ) 的 分 析 。 


13.4.1 reexec.Init( ) 的 分 析 


reexec.Init( ) 在 本 书 中 并 非 第 一 次 出 现 ， 早 在 第 2 章 中 ,创建 
Docker Client 时 就 涉及 了 reexec.lnit( ) ,当时 在 docker 的 main 
约 数 的 运行 中 ， 第 一 个 步骤 即 检验 reexec.Init( ) 的 值 , 第 二 个 步 又 
才 是 解析 flag 参 数 ， 由 于 还 没有 execdriver 等 概念 的 基础 ， 故 没有 深 
入 。 具 体 源码 位 于 ./docker/docker/docker.go#L26-L111 , 如 下 : 
func main() { 


if reexec.Init() { 
return 


} 
flag.Parse() 
// FIXME: validate daemon flags here 


Docker 中 包 reexec 的 存在 ,主要 是 因为 使 用 Go 在 派生 进程 时 存 
在 一 些 语言 层 的 限制 。 功 能 上 ,reexec 使 得 dockerinit 这 个 二 进 制 文 
件 可 以 运行 多 种 任务 。dockerinit 运 行 的 处 理 方 法 都 通过 一 个 注册 的 
execdriver 名 称 来 获取 ， 并 最 终 运 行 此 处 理 方法 。 


首先 进入 reexec 包 中 的 Init( ) 国 数 定 义 ， 源 码 实 现 位 
于 ./docker/docker/reexec/reexec.go#L23-L32 , 如 下 : 


func Init() booL { 
initializer, exists := registeredInitiaLizers[os.Args[0]] 
if exists { 
initializer() 
return true 


} 
return false 


以 上 代码 表明 : Init( ) 将 会 执行 注册 的 initializer。 既 然 是 注册 
的 initializer， 就 会 存在 一 个 问题 :“Docker 中 哪 一 模块 注册 了 相应 
的 initializer ?”。 由 于 reexec 包 的 功能 大 部 分 与 exec 相 关 ，, 而 在 
Docker 架 构 中 ,与 exec 关 系 最 紧密 的 自然 是 execdriver ， 
execdriver 负 责 执 行 容 郑 的 相应 操作 ， 而 问题 的 答案 恰巧 的 确 是 


execdriver, 


以 默认 的 execdriver 为 例 ,也 就 是 类 型 为 native 的 
execdriver , Docker Daemon 启 动 时 自然 会 初始 化 execdriver ， 
而 在 初始 化 类 型 为 native 的 execdriver 时 ,会 执行 execdriver 对 
reeXxec 的 注册 ， 代 码 位 
于 ./docker/docker/daemon/execdriver/native/init.go#L19- 


L21 ,如 下 : 


func init() { 
reexec.Register(DriverName, initializer) 
} 


纹 数 initt ) 实现 了 DriveName 的 注册 ,DriveName 的 值 
为 “native”, 而 注册 时 相应 的 处 理 方法 为 initializer ,此 initializer 才 
是 dockerinit 真 正 运行 的 内 容 。 反 观 createCommand 环 节 ， 


dockerinit 的 参数 中 第 一 个 是 DriveName( “native”) ， 故 


dockerinit 运 行 时 将 直接 执行 key 为 “native "的 注册 处 理 方法 。 而 
在 ./dockerdockerdockergo 的 main 纯 数 中 ， 一 旦 由 于 某 种 异常 原 
, reexec.Init( ) 已 经 有 注册 的 值 , 而 Docker Daemon 局 动 的 过 
程 中 仍然 需要 向 reexec 注 册 相 应 的 execdriver ,两 者 很 有 可 能 造成 
冲突 。 因 此 ，dockergo 中 main 组 数 确保 当前 没有 注册 execdriver 
之 后 ， 再 继续 往 下 执行 。 


13.4.2 dockerinit 的 执行 流程 


dockerinit 的 执行 流程 ， 可 以 说 就 是 initializer 的 执行 流程 。 在 功 
能 方面 ,initializer 依 旧 完 成 一 部 分 初始 化 工作 ， 并 在 最 后 把 控制 权 
交 给 libcontainer 的 namespace ,由 后 者 完成 剩余 容 左 的 初始 化 工 
人 


类 型 为 “native” 的 initializer 的 源码 实现 位 
于 ./docker/docker/daemon/execdriver/native/init.go#L19- 


L21 ,如 下 : 


func initializer() { 
runtime.LockOSThread() 


var ( 
pipe = flag.Int("pipe", 0, "sync pipe fd") 
console = flag.String("console", "", "console (pty slave) path") 
root = flag.String("root", ".", "root path for configuration files") 


) 
flag.Parse() 
var container *libcontainer.Config 
f, err := os.O0pen(filepath.Join(*root, "container.]json")) 
if err != nil { 
writeError(err) 
} 


if err := json.NewDecoder(f).Decode(&container); err != nil { 
f.CLose() 
writeError(err) 

} 

f.Close() 

rootfs, err := 0s.Getwd!() 

if err != nil { 
writeError(err) 


syncPipe, err := syncpipe.NewSyncPipeFromFd(0, uintptr(*pipe)) 


if err != nil { 
writeError(err) 
} 
if err := namespaces.Init(container, rootfs, *console, syncPipe, 


flag.Args()); err != nil { 
writeError(err) 


} 


panic("Unreachable") 


分 析 initializer 的 实现 ， 发 现 执行 流程 包含 5 个 步 又， 分 别 如 下 : 
1) 定义 flag 参 数 并 解析 ; 


2) 声明 libcontainerConfig 实 例 ,并 通过 解析 containerjson 
文件 , 获取 实例 内 容 。 文 件 cContainerjson : execdriver 中 run 哨 数 
执行 namespaces.eXxec 国 数 之 前 ,将 libcontainerConfig 对 象 实例 
持久 化 至 本 地 有 目 


录 /varlib/dockerexecdrivernative/< c.ID> /containerjson ; 
) 获取 root 的 路 径 ; 


4) 通过 同步 管道 所 在 的 文件 描述 符 索引 值 ( 值 为 3 ， 获取 对 应 
的 管道 对 象 ; 


5) 通过 libcontainer 中 namespaces 包 的 Init 纹 数 ， 最 终 完成 容 
需 初 始 化 工作 。 


时 


13.5 libcontainer 的 运行 


libcontainer 是 一 套 容 器 技术 的 实现 方案 ,借助 于 libpcontainer 的 
调用 ， 可 以 完成 容器 的 创建 与 管理 。dockerinit 就 通过 libcontainer 来 
完成 容器 的 创建 与 初始 化 。 


dockerinit 通 过 namespaces 包 的 Init 负 数 来 调用 libcontainer 的 
API 接 口 并 完成 所 有 工作 , 但 是 Init 完 成 的 内 容 绝 不 仅仅 只 有 与 Linux 
namespace 相 关 的 内 容 。Init 是 全 新 namespace 下 运行 的 第 一 部 分 
内 容 ,同时 会 完成 mount 信 息 、 容 莫 用 户 以 及 网 络 等 多 方面 的 配置 。 


由 于 dockerinit 需 要 与 Docker Daemon 进 行 信 息 同 步 ， 故 几乎 
可 以 将 这 父子 进程 的 管道 同步 作为 一 个 分 水 岭 ， 前半 部 分 作为 进程 的 
配置 ， 后 半 部 作为 初始 化 容 背 的 资源 。Init 纹 数 的 实现 位 
于 ./docker/libcontainer/namespaces/init.go#L32-L122 , 如 
下 


func Init(container *libcontainer.Config, uncleanRootfs, consolePath string, 
syncPipe *syncpipe.SyncPipe, args []string) (err error) { 
if err := LoadContainerEnvironment(container); err != nil { 
return err 


// We always read this as it is a way to sync with the parent as well 
var networkState *network.NetworkState 


if err := syncPipe.ReadFromParent(&networkState); err != nil { 
return err 

} 

if err := setupNetwork(container, networkState); err != nil { 


return fmt.Errorf("setup networking %s", err) 


} 


if err := mount.InitializeMountNamespace(rootfs, 
consolePath, 
container.RestrictSys, 
(*mount .MountConfig) (container.MountConfig)); err != nil { 
return fmt.Errorf("setup mount namespace %s", err) 


if err := FinalizeNamespace(container); err != nil { 
return fmt.Errorf("finalize namespace %s", err) 


// FinalizeNamespace can change user/group which clears the parent death 
// signal, so we restore it here. 
if err := RestoreParentDeathSignal(pdeathSignal); err != nil { 
return fmt.Errorf("restore parent death signal %s", err) 
上 


return system.Execv(args[0], args[0:], os.Environ()) 


dockerinit 通 过 向 syncPipe 读 取 父 进程 Docker Daemon 传 递 的 
内 容 ， 完 成 两 者 信息 的 同步 。Docker Daemon 与 dockerinit 的 同步 
流程 如 图 13-1 所 示 。 
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13-1 Docker Daemon 与 dockerinit 的 同步 流程 


通过 图 13-1 我 们 可 以 发 现 ，Docker Daemon 通 过 libcontainer 
中 namespaces 包 的 exec 员 数 执 行 Command.Start( ) 之 后 , 仍 有 
其 他 的 工作 需要 完成 ， 主 要 工作 如 下 : 


1) SetupCgroups , 设置 dockerinit 进 程 的 cgroups ，, 完成 
dockerinit 进 程 的 资源 限制 ; 


2) InitializeNetworking , 创建 dockerinit 所 在 容 冀 的 网 络 材 资 
产 ; 


3) syncPipe.ReadFromChild , 与 子 进 程 dockerinit 同 步 。 


回 到 Docker Daemon 的 namespaces.Exec 中 ,下面 分 析 执 行 


流程 : 


13.5.1 Docker Daemon 设 置 cCgroups 参 数 


SetupCgroups 通 过 类 型 为 libcontainerConfig 的 container 对 
象 以 及 dockerinit 进 程 在 宿主 机 上 的 PID 号 ， 为 dockerinit 设 置 
cgroups 参 数 ， 从 此 cgroups 对 dockerinit 进 程 的 资源 限制 生效 , 而 
之 后 dockerinit 进 程 派生 出 的 子 进程 也 将 受到 相同 的 资源 限制 。 


资源 的 使 用 受到 应 有 的 限制 ， 是 容 问 技术 的 一 大 亮 尽 。 实 现 原理 
则 是 在 进程 运行 之 后 ， 通 过 将 进程 的 PID 放 置 于 特定 的 cgroups 子 系 
统 来 完成 。 


13.5.2 ”Docker Daemon 创建 网 络 栈 资 源 


创建 容 旭 网 络 栈 资源 依靠 销 数 InitializeNetworking , 调用 者 
Docker Daemon 一 般 位 于 init 命 名 空间 中 ， 而 dockerinit 位 于 新 建 
的 网 络 命名 空间 中 ， 因 此 InitializeNetworking 的 作用 是 在 init 命 名 空 
间 中 创建 dockerinit 所 在 容 希 需要 的 网 络 栈 资 源 ， 即 跨越 网 络 命名 空 
间 创 建 相 应 的 网 络 栈 。 原 则 上 ， 在 go 语言 的 运行 时 中 ， 并 不 具备 跨 
namespace 的 资源 操纵 能 力 ， 故 Docker Daemon 将 创建 完毕 的 网 
络 栈 资源 通过 syncPipe 的 形式 传递 给 处 于 新 建 hamespace 下 的 
dockerinit ,由 dockerinit 负 责 接收 并 初始 化 新 建 namespace 下 的 
网 络 栈 。 关 于 InitializeNetworking 响 数 的 具体 实现 ， 可 参考 第 7 


= 二 


早 。 


Docker Daemon 通 过 管道 将 网 络 栈 信 息 传递 至 dockerinit 之 
后 ,容器 启动 使 命 就 完成 了 。Docker Daemon 退 居 幕 后 之 时 ， 
dockerinit 才 刚 开 始 大 展 手 脚 。 


13.5.3 dockerinit 配 置 网 络 栈 


虽然 Docker Daemon 已 经 完成 自己 的 使 命 ， 但 是 dockerinit 依 
旧 处 于 阻塞 状态 ,而且 等 待 着 SyncPipe 中 Docker Daemon 传 来 的 内 
容 。 只 要 从 syncPipe 中 读 到 内 容 ，dockerinit 即 从 阻塞 状态 恢复 执 
行 。 在 设置 SID( Session ID) 、 处 理 tty 等 一 系列 操作 之 后 ， 
dockerinit 最 为 重要 的 工作 就 是 配置 网 络 枝 ， 即 通过 Docker 
Daemon 在 syncPipe 中 传递 来 的 NetworkState 信 息 ， 配置 容器 所 在 
网 络 命名 空间 下 的 网 络 栈 。 


首先 来 看 NetworkState 的 定义 ,位 
于 ./docker/libcontainer/network/types.go#L34-L41 , 如 下 : 


type NetworkState struct { 
// The name of the veth interface on the Host. 
VethHost string ‘json:"veth host,omitempty' 
// The name of the veth interface created inside the container for the child. 
VethChild string ‘json:"veth child,omitempty"™ 
// Net namespace path. 
NsPath string .json:"ns path,omitempty". 


源码 注释 对 于 NetworkState 各 属性 的 描述 非常 到 位 ， 结合 
Docker 的 网 络 模 式 来 分 析 ，, 便 可 发 现 : VethHost 和 VethChild 属 于 
bridge 网 络 模式 下 的 veth pair ,前 者 是 答 主 机 上 依附 在 网 桥 docker0 
上 的 veth , 而 后 者 是 容 莫 内 部 的 veth ; NsPath 属 于 other container 


网 络 模式 下 其 他 容 关 的 网 络 命名 空间 路 径 。 之 所 以 NetworkState 中 没 
有 host 网 络 模式 以 及 none 网 络 模式 的 信息 ， 原 因 很 简单 ，host 网 络 模 
式 不 需要 为 容 背 创 建新 的 网 络 命名 空间 , 而 none 网 络 模式 不 做 任何 网 
络 配置 。 


以 bridge 网 络 模式 为 例 , SetupNetwork 多 数 正 是 利用 
NetworkState 中 的 网 络 接口 ( veth pain 配置 信息 ， 在 容 闫 的 网 络 
命名 空间 下 初始 化 内 部 网 络 接口 ， 将 其 改名 为 eth0， 并 对 网 络 接口 的 
MTU、1P 地 址 以 及 默认 网 关 地 址 进行 配置 。 


SetupNetwork 噬 数 的 实现 过 程 中 ， 主 要 通过 NetworkStrategy 
从 containerNetworks 对 象 中 的 Type 获取 所 需 初始 化 的 网 络 接口 类 
型 ， 并 通过 具体 类 型 进行 相应 的 配置 。 若 网 络 接口 类 型 为 veth， 则 网 
络 配置 工作 的 源码 实现 位 
于 ./docker/libcontainer/network/veth.go#L52-L77 , 如下: 


func (v *Veth) Initialize(config *Network, networkState *NetworkState) error { 
var vethChild = networkState.VethChild 
If vethChild == "" { 
return fmt.Errorf("vethChild is not specified") 


} 
if err := InterfaceDown(vethChild); err != nil { 
return fmt.Errorf("interface down %s %s", vethChild, err) 
if err := ChangeInterfaceName(vethChild, defaultDevice); err != nil { 
return fmt.Errorf("change %s to %s %s", vethChild, defaultDevice, err) 
if err := SetInterfaceIlp(defaultDevice, config.Address); err != nil { 
return fmt.Errorf("set %s ip %s", defaultDevice, err) 
if err := SetMtu(defaultDevice, config.Mtu); err != nil { 
return fmt.Errorf("set %s mtu to %d %s", defaultDevice, config.Mtu, err) 
} 
if err := InterfaceUp(defaultDevice); err != nil { 


return fmt.Errorf("%s up %s", defaultDevice, err) 


} 
if config.Gateway != "" { 
if err := SetDefaultGateway(config.Gateway, defaultDevice); err != nil { 
return fmt.Errorf("set gateway to %s on device %s failed with 
%s", config.Gateway, defaultDevice, err) 


} 


return nil 


} 
分 析 以 上 Initialize 级 数 的 实现 ， 很 快 可 以 总 结 出 以 下 执行 流程 : 
1) 将 名 为 VethChild 的 网 络 接口 停止 运行 ; 


2) 将 名 为 VethChild 的 网 络 接口 改名 为 defaultDevice， 即 
etho0 :; 


3) 为 网 络 接口 eth0 设 置 IP 地 址 ; 

4) 为 网 络 接口 eth0 设 置 MTU 值 ; 

5) 启动 网 络 接口 eth0 ; 

6) 若 需 设 置 网 天地 址 ， 则 为 网 络 接口 设置 默认 网 关 地 址 。 


通过 以 上 6 个 步 又 的 初始 化 与 配置 ， 容 兹 网 络 命名 空间 内 的 网 络 接 
口 即 成 功 运行 ， 为 容 需 内 部 提供 完整 的 网 络 栈 ， 并 且 该 veth 网 络 接口 
对 其 他 容 颖 不 可 见 ， 处 于 独立 的 容 莫 环境 中 ，。 


另外 ， 需 要 说 明 的 是 ， 对 于 容器 技术 而 言 , 只 要 新 建 一 个 网 络 命 
名 空间 ,容器 内 部 就 会 默认 创建 一 个 loopback 网 络 环 回 接口 ， 供 容器 


内 部 本 
地 通信 


13.5.4 dockerinit 初 始 化 mount namespace 


对 于 dockerinit 而 言 ,不 仅 网 络 命名 空间 下 的 网 络 栈 资源 需要 初 
始 化 与 配置 ， 其 他 命名 空间 下 的 资源 同样 需要 初始 化 。 函 数 
InitializeMountNamespace 则 用 于 完成 挂 载 资 源 的 初始 化 。 


Docker 体 系 中 ， 关 于 挂 载 资 源 ，, 无 外 平 有 三 种 基本 的 资源 : 设备 
( device) 、 文 件 系统 以 及 挂 载 吕 mount point) 。 文 件 系 统 资源 
比较 好 理解 ，Docker 容 器 的 运行 离 不 开 文 件 系统 ， 这 样 的 文件 系统 自 
然 包 括 容器 最 初 的 rootfs 文 件 系 统 ， 当 然 也 包含 proc 等 虚拟 文件 系 
统 。 除 此 之 外 ， 如 果 对 Docker 中 volume 概 念 熟悉 ,理解 挂 载 点 
( mount point) 自然 也 不 是 难事 ， 挂 载 点 保证 宿主 机 上 的 文件 资源 
同样 可 以 被 挂 载 到 容器 内 部 ， 并 被 容器 内 部 进程 使 用 。 设 备 文件 的 初 
始 化 ,实则 是 为 容器 的 设备 创建 一 个 索引 节点 并 进行 关联 。 


函数 InitializeMountNamespace 的 定义 位 
于 ./docker/libcontainer/mount/init.go#L29 ,如 下 : 


func InitializeMountNamespace(rootfs, console string, sysReadonly bool, 
mountConfig *MountConfig) error 


其 中 mountConfig 参 数 同 样 来 自 与 containerMountConfig ， 


而 container 的 类 型 为 libcontainerConfig , 它 正 是 execdriver 为 了 


适 配 libcontainer 通 过 将 execdriver.Command 转 义 后 的 
libcontainer.Config。 因 此 ， 用 户 态 所 有 的 mount 人 信息， 最 终 都 会 
在 libcontainer 执 行 InitializeMountNamespace 时 有 所 体现 。 


13.5.5 dockerinit 完 成 namespace 配 置 


dockerinit 的 历史 使 命 并 非 仅仅 是 初始 化 与 配置 容器 的 
namespace , 完成 hamespace 的 相应 工作 之 后 ， 仍然 需要 执行 
户 指定 的 Entrypoint 以 及 Cmd。 两 项 任务 的 分 隅 线 就 以 国 数 


FinalizeNamespace 为 准 。 


顾名思义 ， 在 开始 执行 用 户 命令 之 前 ， 国 数 
FinalizeNamespace 完 成 容器 namespace 下 所 需 的 所 有 工作 。 哨 数 
定义 位 于 ./docker/libcontainer/namespaces/init.go#L211- 


L249 ,如 下 : 


func FinalizeNamespace(container *libcontainer.Config) error { 
// Ensure that all non-standard fds we may have accidentally 
// inherited are marked close-on-exec so they stay out of the 
// container 
if err := utils.CloseExecFrom(3); err != nil { 
return fmt.Errorf("close open file descriptors %s", err) 
} 


// drop capabilities in bounding set before changing user 

if err := capabilities.DropBoundingSet(container.Capabilities); err != nil { 
return fmt.Errorf("drop bounding set %s", err) 

} 


// preserve existing capabilities while we change users 
if err := system.SetKeepCaps(); err != nil { 
return fmt.Errorf("set keep caps %s", err) 


if err := SetupUser(container.User); err != nil { 
return fmt.Errorf("setup user %s", err) 


if err := system.ClearKeepCaps(); err != nil { 
return fmt.Errorf("clear keep caps %s", err) 


// drop all other capabilities 
if err := capabilities.DropCapabilities(container.Capabilities); err != nil 


return fmt.Errorf("drop capabilities %s", err) 


if container.WorkingDir != "" { 
if err := syscall.Chdir(container.WorkingDir); err != nil 
return fmt.Errorf("chdir to %s %s", container.WorkingDir, err) 


return nil 
以 上 代码 逻辑 全 部 顺序 执行 ， 逻 步 分 析 执 行 步 又 ,可 以 得 到 以 下 
结果 : 


1) CloseExecFrom( 3) ， 关闭 除 标准 输入 ( 文件 描述 符 为 
0) 、 标 准 输出 ( 文件 描述 符 为 ]) 、 标 准 错误 ( 文件 描述 符 为 2) 之 
外 所 有 打开 的 文件 描述 符 ( 文件 描述 符 大 于 等 于 3) 


2) DropBoundingSet , 在 容 莫 切换 用 户 之 前 ， 为 容 右 取消 某 些 
Linux Capability ; 


3) SetKeepCaps , 在 容 右 切换 用 户 前 ， 为 容 右 保留 已 经 拥有 的 
Linux Capability ; 


4) SetupUser , 为 容 右 创建 新 的 用 户 ID、 组 ID、 补 充 组 的 ID 以 
及 用 户 的 Home 目 录 ; 


5) ClearKeepCaps， 清除 所 有 保留 的 Linux Capability ; 


6) DropCapabilities ,禁用 其 他 所 有 的 Linux Capability ; 


7) syscall.Chdir( _ containerWorkingDin ， 为 容器 进程 切换 
至 工作 目录 workdir , 即 在 用 户 态 docker run 命 令 指 定 的 参数 


workdir, 


通过 以 上 7 个 步骤 ,dockerinit 的 namespace 初 始 化 工作 圆满 完 
成 ， 一 个 备 受 瞩目 的 容器 才 真 正 诞 生 ， 因为 容器 的 隔离 、 资 源 控制 、 
权限 管理 等 在 这 一 刻 才 全 部 完成 。dockerinit 在 容 闫 的 证 生 阶段 扮演 
一 个 先行 官 的 角色 ， 然 而 ， 对 于 最 终 的 用 户 而 言 ，dockerinit 显 然 不 
是 主角 ， 用 户 希 望 自己 指 定 的 应 用 程序 最 终 能 在 容器 内 按 预期 正常 运 


/一 


位 。 


13.5.6 dockerinit 执 行 用 户 命令 Entrypoint 


回 到 namespaces 包 的 Init 汐 数 , 在 FinalizeNamespace 之 后 ， 
dockerinit 立 即将 容 右 主 进程 的 执行 权 交 给 其 他 程序 。 而 这 些 程序 的 
局 动 命令 是 用 户 在 docker run 命 令 或 者 Dockerfile 指 定 的 
Entrypoint 命 令 与 Cmd 命 令 。 


这 部 分 代码 位 于 Init 疯 数 的 最 后 部 分 ,如 下 : 


return system.Execv(args[0], args[0:], os.Environ()) 


代码 言 简 意 凡 ， 通 过 Linux 进 程 的 角度 来 分 析 再 适合 不 过 。 首 

先 ， 从 args 参 数 中 提取 出 第 一 个 参数 作为 执行 命令 ， 第 二 个 开始 所 有 
的 参数 作为 第 一 个 执行 命令 的 运行 参数 ， 而 os.Environ( ) 代表 整个 
进程 运行 时 的 环境 变量 。 同 时 ， 最 为 重要 的 一 点 是 ， 通 过 系统 调用 执 
行 exec 操 作 ， 只 是 在 原 有 进程 的 基础 上 重新 执行 一 段 程序 ， 而 并 不 会 
改变 原 有 进程 的 PID， 也 不 会 创建 一 个 新 进程 。system.Execv 咀 数 
的 定义 位 于 ./docker/libcontainer/system/linux.go#L11-L18 , 如 
下 : 


func Execv(cmd string, args []string, env []string) error { 
name, err := exec.LookPath(cmd) 
if err != nil { 
return err 


return syscall.Exec(name, args, env) 


在 Init 约 数 中 ，args 参 数 也 是 在 execdriver 在 传递 
createCommand 郧 数 时 被 同时 传递 至 libcontainer 准 备 。Docker 
体系 中 与 args 参 数 相关 程度 最 高 的 当 属 Entrypoint 与 Cmd , 一 旦 用 
户 指定 了 Entrypoint 或 者 Dockerfile 中 指定 了 Entrypoint ,Docker 
Daemon 在 处 理 用 户 命令 参数 时 ， 就 会 将 Entrypoint 的 内 容 放 在 
Cmd 前 面 ， 一 起 作为 最 终 的 args ; 邦 均 不 存在 Entrypoint , 那么 
Docker Daemon 只 将 Cmd 作 为 最 终 的 args。 因 此 ， 对 于 一 个 
Docker 容 妖 的 配置 而 言 ， 允许 不 存在 Entrypoint , 但 是 必须 要 有 
Cmd。 在 两 者 同时 存在 的 情况 下 ， 局 动容 恬 时 ，Entrypoint 更 偏向 于 
容 堪 应 用 层 的 初始 化 工作 ,在 Entrypoint 中 的 最 后 一 个 步 又， 同样 会 
使 用 exec 系 统 调 用 ， 将 主 进 程 的 执行 权 交 给 Cmd ,毋庸 置疑 ，Cmd 
属于 用 户 指定 运行 的 应 用 程序 。 


虽然 容器 的 启动 经 历 了 dockerinit、Entrypoint 以 及 Cmd , 但 是 
这 三 者 在 运行 时 都 基于 同一 个 PID， 而 整个 容器 的 状态 全 部 依赖 于 这 
个 PID 进 程 的 存活 。 另 外 ， 当 Cmd 在 运行 过 程 中 创建 其 他 子 进程 时 ， 
所 有 子 进 程 都 会 受到 相同 namespace 的 作用 ， 同 时 也 会 受到 控制 组 
等 其 他 内 核 特性 的 作用 。Cmd 进 程 及 其 所 有 子 进程 共同 构成 一 个 用 户 
眼中 的 “容器 ”。 


总 之 ,Docker Daemon、dockerinit、Entrypoint 以 及 Cmd 四 
者 之 间 的 关系 如 图 13-2 所 示 。 


cgroups 





the only process (same PID) 


Docker Container 


图 13-2 Docker Daemon、dockerinit、Entrypoint、Cmd 之 间 
的 关系 


13.6 总 结 


深入 学 习 dockerinit 的 原理 ， 对 于 理解 Docker 容 怖 的 实现 会 有 很 
大 帮助 。 若 对 dockerinit 思 考 得 更 多 ， 则 可 以 发 现 dockerinit 的 局 
动 , 即 Docker 容 闫 的 启动， 完全 是 借助 Linux 内 核 的 众多 特性 在 做 工 
作 。 从 Linux 内 核 的 角度 来 看 待 Docker 容 器 ， 容 器 技术 的 实现 手段 并 
非 深 不 可 测 ， 容 颖 毕竟 和 宿主 机 共享 同一 个 Linux 内 核 ， 所 有 工作 都 
通过 内 核 来 完成 。 


Docker 容 需 的 成 功 创建 ， 可 以 说 是 Docker Daemon 与 
dockerinit 协 同 合 作 的 结果 。Docker Daemon 创 建 一 个 初步 的 容器 
环境 ,并 将 容 右 环境 的 初始 化 工作 交 给 dockerinit 来 完成 ， 同 时 两 者 
之 间 完 成 起 码 的 通信 。dockerinit 的 运行 起 到 一 个 承前启后 的 作用 ， 
它 不 仅 接受 Docker Daemon 的 使 命 ， 完成 容器 环境 的 初始 化 ,同时 
还 负责 将 容 硕 的 运行 转变 为 用 户 应 用 程序 Cmd 的 运行 ， 并 将 容 希 交付 
给 Docker 用 户 。 
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14.1 引言 


在 Docker 圈 ,大 家 也 许 听 说 过 这 样 类 似 于 这 样 的 话 “Docker 的 本 
质 并 非 是 新 颖 的 技术 ， 容 器 技术 也 早已 诞生 多 年 "。 可 以 说 ,此 言 没 有 
半点 夸大 。 在 Docker 之 前 ，Linux 平 台 上 以 LXC 为 代表 的 一 系列 容 善 
技术 早已 在 历史 舞台 上 活跃 多 年 。 对 于 包括 Docker 在 内 的 多 种 容器 技 
术 ， 最 终 的 容 需 都 离 不 开 Linux 内 核 的 很 多 高 级 特性 ， 如 : 


namespace、cgroup 等 。 


Docker 架 构 中 ，Docker Daemon 作 为 一 个 常 驻 进程 ， 管理 
Docker Client 请 求 的 同时 ， 还 管理 所 有 的 Docker 容 器 。 而 Linux 操 
作 系 统 内 核 态 对 容 右 的 管理 ,自然 需要 为 用 户 仿 的 Docker Daemon 
服务 ， 因 此 如 果 在 Docker Daemon 与 Linux 内 核 之 间 有 一 套 完善 的 
API 接 口 ， 那 么 两 者 的 衔接 将 变 得 尤为 顺畅 。Docker 的 发 展 历程 中 ， 
0.9.0 版 本 即 引 入 了 libcontainer 模 块 ， 这 意味 着 内 核 API 接 口 的 横 空 
出 世 。 


简单 而 言 , libcontainer 是 一 套 实现 容器 管理 的 Go 语言 解决 方 
案 。 这 套 解决 方案 实现 过 程 中 使 用 了 Linux 内 核 特 性 namespace 与 


cgroup， 同时 还 采用 了 capability 与 文件 权限 控制 等 其 他 一 系列 技 
术 。 基 于 这 些 特 性 ， 除了 创建 容器 之 外 ，libcontainer 还 可 以 完成 管 
理 容器 生命 周期 的 任务 。 


Docker 容 器 提供 一 个 隔离 、 独 立 的 环境 ， 富 不 过 分 地 说 ， 这 样 的 
效果 完全 离 不 开 libcontainer 的 功劳 。 隔 离 的 效果 自然 是 容 钴 内 部 与 
容 大 外 部 的 隔离 ， 然 而 ， 对 于 实现 此 功能 的 libcontainer 而 言 需要 
完成 的 工作 正 像 容器 内 外 一 样 ， 既 需要 在 容器 外 做 容器 的 配置 与 管 
理 ， 同时 还 需要 在 容 希 内 部 完成 相应 的 初始 化 工作 。 


另外 ，, 需要 提 及 的 是 ， libcontainer 作 为 一 个 提供 内 核 API 接 口 的 
容 蓝 技术 解决 方案 ， 设 计 之 初 就 以 简洁 方便 为 目的, 以 至 于 
libcontainer 的 生成 与 运行 没有 任何 依赖 。 作 为 纯粹 并 且 接 口 完备 的 
容 希 管理 工具 , libcontainer 似 乎 有 反 向 定义 Linux 容 冀 技 术 的 含 
义 ， 尝 试 成 为 容 莫 技术 的 新 生 标 准 。 同 时 ，libcontainer 的 设计 似乎 
也 让 开发 者 看 到 了 Docker 跨 平台 的 潜在 能 力 。Docker Daemon 负 
责 Docker Server 的 一 系列 API 接 口 ,而 libcontainer 接 管 Linux 平 台 
内 核 态 容 器 技术 实现 的 API 接 口 ， 两 者 通过 execdriver 的 形式 协调 工 
作 。 如 此 一 来 ， 在原 有 Docker Server 的 API 接 口 下 ,似乎 蔡 换 其 他 
平台 的 底层 容 右 实现 技术 的 接口 即 可 ， 如 在 Solaris 操 作 系统 下 ， 开 发 
一 个 类 似 于 libcontainer 的 库 ， 兼 容 Docker Daemon 的 API 接 口 ， 


而 实现 Solaris 的 底层 容器 技术 。 因 此 ，Docker 今 后 在 跨 平 台 方面 的 
能 力 绝 不 可 低估 。 


14.2 Docker、libcontainer 以 及 LXC 的 关系 


Docker 的 热潮 席卷 全 球 ， 没 有 适应 于 如 此 节奏 的 技术 爱好 者 ,或 
者 曾 在 类 似 于 LXC 技 术 方 面 有 所 研究 的 开发 者 ,肯定 会 如 此 发 问 : 
Docker 与 LXC 的 区 别 到 底 在 哪里 ? 


从 底层 技术 栈 而 言 ， 似乎 区 别 不 大 ，Linux 的 内 核 特性 不 仅 LXC 
可 以 使 用 , Docker 可 以 使 用 ,而且 任 何 第 三 方 的 容 右 技术 提供 商 均 可 
以 基于 此 进行 开发 。 


从 软件 生命 周期 来 讲 ， 两 者 则 存在 很 大 的 差异 。Docker 可 以 这 样 
认为 : 一 个 Docker Daemon 管 理 众多 的 容器 ，Docker Daemon 为 
常 驻 的 后 台 进 程 。 而 LXC 则 是 一 个 工具 ， 装 有 LXC 的 宿主 机 上 并 没有 
一 个 与 LXC 相 关 的 常 驻 进程 在 后 台 运 行 。 当 用 户 发 起 与 容 莫 相关 的 创 
建 与 管理 命令 后 ，LXC 以 进程 的 形式 来 处 理 命令 ， 命 令 完 成 后 进程 立 
即 退出 。 


既然 Docker 最 终 也 需要 创建 与 管理 容 右 ,那么 是 否 也 需要 类 似 于 
LXC 的 工具 呢 ? 答案 是 肯定 的 。 事 实 上 , Docker 0.9.0 以 前 Docker 
正 是 通过 LXC 这 套 工 具 来 完成 底层 容 笑 的 创建 与 管理 ; 而 从 Docker 
0.9.0 开 始 Docker 优 先 选 择 libcontainer 作 为 创建 以 及 管理 容器 的 工 


具 。Docker、libcontainer 以 及 LXC 在 Docker 架 构 中 的 关系 如 图 14- 
1 所 示 。 
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14.3 libcontainer 模 块 分 析 


Docker 容 希 范 畴 内 一 切 与 Linux 内 核 相 关 的 技术 实现 ， 都 可 以 认 
为 是 通过 libcontainer 来 完成 的 。libcontainer 指 定 了 所 有 与 容器 相 
天 的 配置 信息 ， 首 先 自然 是 namespace 与 cgroup 信 息 ， 除 此 之 外 ， 
还 有 容 莫 的 网 络 栈 配置 信息 , 当然 ， 还 包括 容 兹 的 挂 载 点 配置 、 设 备 
信息 等 。 为 实现 与 Linux 内 核 的 通信 , libcontainer 还 包含 模块 
netlink， 完 成 内 核 仿 进 程 与 用 户 态 进程 的 IPC( 进程 间 通 信 ) 等 。 


本 节 主 要 介绍 libcontainer 的 模块 组 成 与 各 模块 功能 ， 对 
libcontainer 的 分 析 均 基于 libcontainer 1.2.0 版 本 。 


14.3.1 _ namespace 


namespace 是 libcontainer 的 左 膀 右 臂 ， 可 以 说 没有 隔离 即 不 
存在 容器 。 对 于 一 个 容器 而 言 ， 从 它 诞 生 的 那 一 刻 起 , namespace 
就 已 经 开始 为 容 问 发 挥 作用 了 。Linux 操 作 系统 中 ， 创建 进 程 一 般 会 
使 用 fork 等 系统 调用 。 创 建 进程 时 ， fork 等 系统 调用 完成 子 进程 对 父 
进程 task_struct 的 复制 ， 且 fork 系 统 调 用 时 可 以 传 入 众多 与 
namespace 相 关 的 flag 参 数 。 而 Linux 操 作 系 统 通过 exec 来 启动 子 
进程 的 运行 。 回 到 容 闫 的 创建 ， 由 于 容 硕 的 本 质 也 是 进程 ， 故 在 派生 
进程 时 ，Docker Daemon 传 入 了 与 namespace 相 关 的 flag 参 数 ， 
实现 namespace 的 创建 ， 确 保 容器 ( 进程 ) 被 执行 之 后 ,也 就 是 在 
进程 在 运行 时 达到 namespace 隔 离 的 效果 。 


目前 在 namespace 方 面 , libcontainer 有 以 下 支持 ， 源 代码 位 
于 ./docker/libcontainer/namespaces/types linux.go#L7- 


L16 ,如 下 : 


func init() { 
namespaceList = Namespaces{ 

{Key: "NEWNS", Value: syscall.CLONE NEWNS, File: "mnt"}, 
{Key: "NEWUTS", Value: syscall.CLONE NEWUTS, File: "uts"}, 
{Key: "NEWIPC", Value: syscall.CLONE NEWIPC, File: "ipc"}, 
{Key: "NEWUSER", Value: syscall.CLONE NEWUSER, File: "user"}, 
{Key: "NEWPID", Value: syscall.CLONE NEWPID, File: "pid"}, 
{Key: "NEWNET", Value: syscall.CLONE NEWNET, File: "net"}, 


值得 一 提 的 是 ， 虽 然 namespace 中 加 入 了 用 户 命名 空间 ， 但 是 
libcontainer 由 于 一 些 特殊 原因 却 并 未 将 其 完全 实现 。 另 外 ， 对 于 网 
络 命名 空间 的 支持 ， 也 要 视 用 户 对 容 硕 的 需求 而 定 ， 若 用 户 指定 容器 
的 网 络 模式 为 host 模 式 ， 则 libcontainer 不 为 容 怖 创建 新 的 网 络 命名 


空间 。 


namespace 的 完全 生效 ， 并 不 仅仅 依靠 namespace 的 创建 ， 
同时 还 需要 对 每 一 个 namespace 进 行 初始 化 。 如 mount 命 名 空间 、 
网 络 命名 空间 、uts 命 名 空间 等 命名 空间 需要 Docker Daemon 提 供 


初始 化 信息 ,而 其 他 命令 空间 则 六 用 默认 值 。 
1.namespace 的 创建 


为 容器 创建 namespace 完 全 是 Docker Daemon 的 职责 范畴 ， 
Docker Daemon 一 方面 从 自身 所 在 namespace 创 建新 的 
namespace 服 务 于 容 闫 ， 另 一 方面 在 容 着 namespace 之 外 ,为 容 
辟 配 置 namespace 之 内 所 需 的 命名 空间 资源 。libcontainer 的 源码 
中 ， 内 部 定义 的 exec 隙 数 实现 了 这 部 分 内 容 , 位 


于 ./docker/libcontainer/namespaces/exec.go#1L24 : 


func Exec(container *libcontainer.Config, stdin io.Reader, stdout, stderr 
io.Writer, console string, rootfs, dataPath string, args []string, createCommand 


CreateCommand, startCallback func()) (int, error) { 

syncPipe, err := Syncpipe.NewSyncPipe() 

command := createCommand(container, console, rootfs, dataPath, 
os.Args[0], 


syncPipe.Child(), args) 


if err := command.Start(); err != nil { 
return -1, err 


} 
started, err := system.GetProcessStartTime(command.Process.Pid) 
if err != nil { 
return -1, err 
} 
cgroupRef, err := SetupCgroups(container, command.Process.Pid) 
var networkState network.NetworkState 
if err := InitializeNetworking(container, command.Process.Pid, 
syncPipe, 
S&networkState); err != nil { 
command.Process .Kill() 
command .Wait () 
return -1, err 
state := &libcontainer.State{ 
InitPid: command .Process.Pid， 
InitStartTime: started, 
NetworkState: networkState, 
CgroupPaths: cgroupPaths, 
if err := libcontainer.SaveState(dataPath, state); err != nil { 


command.Process.Kill() 
command.Wait() 
return -1, err 
} 
defer libcontainer.DeleteState(dataPath) 
// Sync with child 
if err := syncPipe.ReadFromChild(); err != nil { 
command.Process.Kill() 
command.Wait() 
return -1, err 


} 


return command.ProcessState.Sys().(syscall.wWaitStatus).ExitStatus(), nil 


Libcontainer 中 namespace 的 exec 实 现 ， 具体 完成 的 主要 工作 
有 : 


1) 创建 syncpipe， 以 便 后 续 Docker Daemon 与 容器 进程 跨 


namespace 进 行 信息 传递 ; 


2) 创建 容 闫 内 部 第 一 个 进程 的 可 执行 命令 ; 


3) 局 动 该 命令 实现 namespace 的 创建 ; 
4) 为 容器 的 第 一 个 进程 进行 cgroup 的 限制 ; 


5) 在 Docker Daemon 所 在 namespace 中 初始 化 容器 内 部 所 需 
的 网 络 资源 ， 以 便 后 续 通过 管道 的 形式 将 资源 传递 至 容 右 内 部 ; 


6) 通过 管道 跨 namespace 将 网 络 资源 传递 至 容器 进程 。 
2.namespace 初 始 化 


Docker Daemon 将 容 硕 所 需要 的 资源 配置 信息 通过 两 种 途径 传 
递 至 容 闫 ， 分 别 为 : 携带 网 络 资源 信息 的 syncpipe 以 及 Docker 
Daemon 持 久 化 到 | 答 主 机 的 container.json 文 件 。 第 13 章 分 析 过 容 医 
内 第 一 个 进程 为 dockerinit , 正 是 dockerinit 完 成 了 容器 自身 
namespace 内 部 挂 载 资 源 、 用 户 资源 、 网 络 资源 等 的 初始 化 工作 。 
该 部 分 内 容 实现 位 


于 ./docker/libcontainer/namespaces/init.go#32-L122 : 


func Init(container *libcontainer.Config, uncleanRootfs, consolePath string, 
syncPipe *syncpipe.SyncPipe, args []string) (err error) { 


if err := LoadContainerEnvironment (container); err != nil { 
return err 


// We always read this as it is a way to sync with the parent as well 
var networkState *network.NetworkState 


if err := syncPipe.ReadFromParent(&networkState); err != nil { 
return err 

} 

if , err := syscall.Setsid(); err != nil { 


return fmt.Errorf("setsid %s", err) 


} 


if err := setupNetwork(container, networkState); err != nil { 
return fmt.Errorf("setup networking %s", err) 


} 

if err := mount.InitiaLizeMountNamespace(rootfs， 
consolePath, 
container.RestrictSys, 
(*mount.MountConfig) (container.MountConfig)); err != nil { 
return fmt.Errorf("setup mount namespace %s", err) 

} 

if err := label.SetProcessLabel (container.ProcessLabel); err != nil { 
return fmt.Errorf("set process label %s", err) 

} 

if err := FinalizeNamespace(container); err != nil { 
return fmt.Errorf("finalize namespace %s", err) 

} 


return system.Execv(args[0], args[0:], os.Environ()) 


容器 的 整个 生命 周期 中 , namespace 是 最 为 基础 的 一 块 。 
ee 简单 的 理解 
: 隔离 的 环境 创建 完毕 之 后 ,内 部 环境 的 初始 化 才能 登场 。 


14.3.2 cgroup 


cgroup 是 Linux 内 核 的 一 个 特性 ， 此 特性 可 以 帮助 用 户 对 一 组 进 
程 进 行 资源 使 用 的 限制 、 统 计 以 及 隔离 。Docker 领 域 也 不 例外 ， 
Docker 利 用 对 cgroup 的 支持 ， 完 成 对 Docker 容 姨 进 程 组 的 资源 限 
制 、 统 计 以 及 隔离 。 


与 cgroup 内 容 相关 的 Cgroup 定 义 ， 位 
于 ./dockerlibcontainercgroups/cgroups.go#L40-L55 , 如 下 : 


type Cgroup struct { 


Name string 


Parent string // name of parent cgroup or slice 
AllowAllDevices bool // If this is true allow access to any kind of 
device within the container. If false, allow access only to devices explicitly 
listed in the allowed devices list. 


AllowedDevices []*devices.Device 
Memory int64 // Memory limit (in bytes) MemoryReservation int64 
// Memory reservation or soft limit (in bytes) MemorySwap int64 // 


Total memory usage (memory + swap); set . -1' to disable swap 


CpuShares int64 // CPU shares (relative weight vs. other 
containers) 


CpuQuota int64 // CPU hardcap limit (in usecs). Allowed cpu 
time in a given period. 


CpuPeriod int64 // CPU period to be used for hardcapping 
(in usecs). 0 to use system default. 


CpusetCpus string // CPU to use Freezer FreezerState 
// set the freeze value for the process Slice string // Parent 
slice to use for systemd } 


从 结构 体 Cgroup 的 定义 可 见 ,Docker 对 于 cgroup 的 支持 , 主 
要 有 以 下 5 方面 : 设备 (device) 、 内 存 ( Memory) 、CPU、 
Freezer 以 及 systemd。 在 容 颖 设备 方面 ，Docker 支 持 让 用 户 选 择 容 
颖 可 以 使 用 的 设备 。 在 内 存 方面 ， 支 持 为 容 颖 的 运行 设 定 用 量 限额 。 
在 CPU 方面 ， 支 持 容器 进程 之 间 拥 有 相对 的 运行 时 间 片 。Freezer 则 | 
可 以 使 容器 挂 起 ， 节 省 CPU 资源 ，Docker 命 令 中 pause 与 unpause 
命令 即 采 用 了 cgroup 的 Freezer 子 系统 。 需 要 注意 的 是 ， 容 姑 进 程 组 
挂 起 ， 并 不 意味 着 进程 已 经 终止 ， 从 Linux 内 核 的 角度 来 看 ， 被 挂 起 
的 进程 拥有 完整 的 task_struct , 占用 相应 的 内 存 ， 但 是 Freezer 子 系 
统 保证 容器 中 的 进程 不 会 被 CPU 调 度 人 到。Slice 属 性 则 属于 systemd 
方面 的 配置 。 


14.3.3 网 络 


Docker 的 网 络 一 直 是 一 个 备 受 关注 的 技术 点 。 目前， 关于 容器 网 
络 的 管理 ， 底层 实现 全 部 借助 libcontainer 的 network 包 来 完成 。 
network 包 定义 了 Docker 容 莫 的 网 络 栈 类 型 。Docker 容 兹 的 网 络 模 
式 有 : bridge 模 式 、host 模 式 、other container 模 式 以 及 none 模 
式 。 这 4 种 网 络 模式 对 网 络 环境 的 配置 分 别 如 下 。 


bridge 模式 : 为 容器 配置 veth 网 络 接口 对， 并 配置 loopback 接 


host 模式 : 不 为 容 闫 创建 网 络 命名 空间 ; 


other container 模 式 : 不 为 容 希 创建 网 络 命名 空间 ， 让 容 需 与 
其 他 容器 共享 网 络 命名 空间 ; 


.none 模式 : 为 容器 创建 网 络 命名 空间 ,配置 loopback 接 口 。 


libcontainer 为 了 标识 网 络 接口 的 数据 接口 ， 抽象 出 network 结 
构 体 ,位 于 ./docker/libcontainer/network/types.go#1L7-L30， 


定义 如 下 : 


type Network struct { 
// Type SetS the networks type, commonly veth and Loopback 
Type string “json:"type,omitempty” 


// Path to network namespace 
NsPath string“` json:"ns_path,omitempty” 
// The bridge to use. 
Bridge string ` json:"bridge,omitempty". 
// Prefix for the veth interfaces. 
VethPrefix string ‘json:"veth prefix,omitempty". 
// Address contains the IP and mask to set on the network interface 
Address string ‘json:"address,omitempty". 
// Gateway sets the gateway address that is used as the default for the 
interface 
Gateway string ` json:"gateway,omitempty” 
// Mtu sets the mtu value for the interface and will be mirrored on 
both the host and 
// container's interfaces if a pair is created, specifically in the 
case of type veth 
// Note: This does not apply to loopback interfaces. 
Mtu int ~ json:"mtu,omitempty". 


Network 结 构 体 代表 容 右 的 网 络 接口 。 容 冀 网 络 接口 类 型 
( Type) 一 般 有 两 种 : veth 和 loopback ; NsPath 代 表 容 姨 网 络 命名 
空间 的 所 在 路 径 ; Bridge 代 表 容 器 网 络 使 用 的 网 桥 设 备 名 ; 
VethPrefix 代 表 容 器 veth 网 络 接口 名 的 前 级 ; Address 和 Gateway 
分 别 代表 容 毁 网络 接口 的 IP 地 址 以 及 网 关 地 址 ; 最 后 ,Mtu 则 代表 容 
妖 网 络 接口 设备 的 MTU 值 。 


14.3.4 挂 载 


文件 系统 的 使 用 ，Docker 容 希 绝 不 仅 限 于 镜像 所 提供 的 rootfs。 
volume 的 存在 ( 包括 bind-mount 以 及 data volume) 使 得 容器 的 
文件 系统 可 以 共享 宿主 机 的 资源 。 除 了 volume 之 外 ， 容 右 不 少 有 关 
于 容 希 信息 的 配置 文件 ,也 是 通过 挂 载 ( mount) 的 形式 使 得 容器 可 
以 使 用 mount 命 名 空间 之 外 的 资源 ， 这 样 的 配置 文件 包括 


hostname、hosts 以 及 resolv.conf 。 


libcontainer 对 于 Mount 对 象 的 定义 位 
于 ./docker/libcontainer/mounts/types.go#L28-L35 , 如 下 : 


type Mount struct { 
Type string “json:"type,omitempty". 
Source string “json:"source,omitempty"™ 
// Source path, in the host namespace 
Destination string ` json:"destination,omitempty". 
// Destination path, in the container 
Writable bool “json:"writable,omitempty"™ 
Relabel string “json:"relabel,omitempty". 
// Relabel source if set, "z" indicates shared, "Z" indicates unshared 
Private bool “json:"private,omitempty". 


对 于 Docker Daemon 而 言 ， 记录 Mount 的 源 地 址 以 及 目 标 地 址 
无 疑 是 最 重要 的 。 在 此 基础 上 ，, 再 对 Mount 对 象 进 行 一 些 属性 配置 ， 
如 Mount 对 象 是 人 否 开局 容 希 的 写 权 限 等 。 


14.3.5 设备 


对 于 容 顺 而 言 ， 使 用 Linux 内 核 管辖 范围 内 的 设备 ， 是 一 个 非常 
基本 的 需求 。libcontainer 则 使 用 devices 包 来 为 Docker 容 器 提供 相 
应 的 设备 。 


libcontainer 对 于 设备 的 定义 位 
于 ./docker/libcontainer/devices/devices.go#L20-L27 , 如 下 : 


type Device struct { 
Type rune ‘json: "type,omitempty"™ 
Path string json:"path,omitempty"™ 
// It is fine if this is an empty string in the case that you are using 
Wildcards 


MajorNumber int64 “json:"major number,omitempty". 
// Use the wildcard constant for wildcards. 

MinorNumber int64 ~ json:"minor number,omitempty"™ 
// Use the wildcard constant for wildcards. 

CgroupPermissions string ~ json:"cgroup permissions,omitempty". 
// Typically just "rwm" 

FiLeMode os.FileMode ` json:"file mode,omitempty” 


// The permission bits of the file's mode 


默认 情况 下 , libcontainer 会 为 容 铸 创建 荣 些 必 备 的 设备 ， 
如 /devwnull、/dev/zero、/dev/full、/dev/tty、/dev/urandom 、/ 


dev/console 等 。 


14.3.6 nsinit 


libcontainer 的 存在 ,使 得 Docker 操 纵 Linux 内 核 特 性 从 而 管理 
容 硕 成 为 可 能 。 既 然 如 此 ， 在 逆向 思维 下 ， 不 少 人 肯定 会 有 疑问 : 如 
果 仅 仅 只 有 libcontainer， 而 没有 更 多 诸如 Docker Daemon 之 类 的 
软件 , 是否 依然 可 以 创建 容 硕 ? 


答案 的 是 肯定 的 ,nsinit 就 是 最 好 的 例子 。nsinit 是 一 个 功能 强大 
的 应 用 程序 ， 该 应 用 程序 巧妙 利用 了 libcontainer , 使 得 容器 的 创建 


变 得 异常 简单 。 若 需要 创建 一 个 容 希 ， 则 按照 libcontainer 的 API 接 
口 ， 必 须要 向 其 提供 容器 的 rootfs 以 及 容器 的 参数 配置 。 因 此 ， 
nsinit 的 运行 需要 提供 一 个 rootfs 以 及 一 个 容 怖 的 配置 文件 
container.json。jSON 文 件 container.json 需 要 处 于 rootfs 的 根 目录 
下 ， 并且 文件 中 含有 的 配置 信息 需要 包括 : 容 颖 的 环境 变量 、 网 络 和 
容器 Capability 等 内 容 。 


14.3.7 ”其 他 模块 


libcontainer 的 组 成 较为 丰富 ， 除 了 以 上 这 些 较 为 重要 的 组 成 部 
分 之 外 ， 其 他 模块 的 存在 也 极 大 地 完善 着 libcontainer 的 功能 。 


libcontainer 完 成 很 多 容器 内 部 的 配置 工作 ， 如 何 真正 与 Linux 
内 核 亲 交道 ， 肯 定 是 libcontainer 必 须要 完成 的 工作 。 Netlink 作 为 
Linux 内 核 的 一 套 接口 ， 提 供 进 程 间 用 户 态 与 内 核 态 之 间 的 通信 方 
起 


在 容器 的 安全 方面 ,libcontainer 由 security 模 块 负 责 。Linux 
的 Capability 机 制作 为 一 项 非常 重要 的 安全 指标 ，Docker 可 以 由 用 户 
来 自 定义 配置 容器 的 Capability ,具体 实现 由 security 包 完成 。 


Capability 的 存在 极 大 地 限制 了 用 户 进程 的 权限 ， 然 而 ,安全 的 
范畴 太 广 ， 不 可 能 全 部 倚 仗 Capability。 由 于 Docker 的 namespace 
没有 完全 实现 用 户 命名 空间 ,因此 Docker 容 器 中 的 超级 管理 员 用 户 
root 与 宿主 机 上 的 root 用 户 是 同一 个 用 户 。 没 有 隔离 用 户 ，, 的 确 是 一 
个 很 大 的 安全 隐患, 然而 ，Docker 通 过 Capability 特 性 尽量 降低 这 方 
面 的 影响 。 可 以 说 ， 使 用 了 Capability 特 性 之 后 ， 在 权限 方面 ， 
Docker 容 器 内 的 root 用 户 和 宿主 机 上 的 root 用 户 有 很 大 的 差别 ， 容器 


内 root 用 户 的 权限 自然 会 小 很 多 。 与 此 同时 ， Docker 还 支持 SELinux 
以 及 Apparmor , 为 容 右 的 安全 保驾 护航 。 


14.4 总 结 


开发 者 普遍 了 解 甚至 掌握 Docker , 却 往往 会 忽视 libcontainer 的 
重要 性 。libcontainer 作 为 容 兹 技术 的 一 种 解决 方案 ,很 好 地 衔接 了 
Docker Daemon 这 个 管理 引擎 与 Linux 的 内 核 特性 。 更 为 直接 的 评 
价 是 : Docker 的 运行 不 能 没有 libcontainer , 而 在 libcontainer 的 其 
础 上 ，, 任何 开发 者 或 团队 都 可 以 开发 或 者 再 造 类 似 Docker 的 容 右 管理 
引擎 。 相 信 Docker 官 方 也 希望 更 多 开发 者 参与 libcontainer 的 维护 工 
作 ,并 努力 推动 其 发 展 , 使 libcontainer 成 为 容 莫 技术 的 标准 ， 从 而 
在 容 希 市 场 上 占据 更 大 的 份额 。 


第 15 章 Swarm 架构 设计 与 实现 
15.1 引言 


Docker 自 诞生 以 来 ， 其 容 希 特性 以 及 镜像 特性 给 DevOps 爱 好 者 
带 来 了 诸多 方便 。 然 而 ， 在 很 长 的 一 段 时 间 内 ，Docker 只 能 在 单 宿主 
机 上 运行 ， 其 跨 宵 主机 的 部 署 、 运 行 与 管理 能 力 鼎 受 外 界 诉 病 。 跨 宿 
主机 能 力 的 薄弱 ， 直 接 导致 Docker 容 器 与 宿主 机 的 紧 耦 合 ， 这 种 情况 
下 ，Docker 容 希 的 灵活 性 很 难 令 人 满意 ， 容 怖 的 迁移 、 分 组 等 都 成 为 
很 难 实现 的 功能 点 。 


Swarm 是 Docker 公 司 在 2014 年 12 月 初 新 发 布 的 容器 管理 工 
具 。 和 Swarm 一 起 发 布 的 Docker 管 理工 具 还 有 Machine 以 及 


Compose。 


Swarm 是 一 套 较 为 简单 的 工具 ， 用 于 管理 Docker 集 群 ， 使 得 
Docker 集 群 暴露 给 用 户 时 相当 于 一 个 虚拟 的 整体 。Swarm 使 用 标准 
的 Docker API 接 口 作为 其 前 端 访问 入 口 ， 换 言 之 ， 各 种 形式 的 
Docker Client( Go 语言 的 客户 端 、docker_ py、docker 等 ) 均 可 
以 直接 与 Swarm 通信 。Swarm 几 乎 全 部 用 Go 语言 来 完成 开发 ， 并 且 
还 处 于 一 个 Alpha 版 本 。 然 而 , Swarm 的 发 展 十 分 快速 ， 功 能 和 特性 


的 变更 迭代 还 非常 频繁 。 因 此 ， 可 以 说 Swarm 还 不 推荐 用 于 生产 环境 
中 ,但 可 以 肯定 的 是 Swarm 是 一 项 很 有 前 途 的 技术 。 


Swarm 的 设计 初 表 和 其 他 Docker 项 目 一 样 ， 遵循 “batteries 
included but removable" 原 则 。 笔 者 对 该 原则 的 理解 是 : 
batteries included 代 表 设计 Swarm 时 ， 为 了 完全 体现 分 布 式 容 器 集 
群 部 署 、 运 行 与 管理 功能 的 完整 性 ，Swarm 和 Docker 协 同 工 作 ， 
Swarm 内 部 包含 了 一 个 较为 简易 的 调度 模块 ， 以 达到 对 Docker 集 群 
调度 管理 的 效果 ;“but removable" 意 味 着 Swarm 与 Docker 并 非 紧 
耦合 ， 同 时 Swarm 中 的 调度 模块 同样 可 以 定制 化 ， 用 户 可 以 按照 自己 
的 需求 ， 将 其 替换 为 更 为 强大 的 调度 模块 ， 如 Mesos 等 。 另 外 ， 这 套 
管理 引擎 并 未 侵入 Docker 的 使 用 ,这 套 机 制 也 为 其 他 容 颖 技术 的 集群 
部 署 、 运 行 与 管理 方式 提供 了 思路 。 


本 章 主 要 从 Swarm 0.2.0 源 码 的 角度 分 析 Swarm 的 架构 设计 与 
实现 。 分 析 内 容 包含 以 下 三 个 步骤 : 


1) Swarm 架构 ; 
2) Swarm 命令 ; 


3) Swarm 运行 。 


15.2 Swarm 架构 


Swarm 作 为 一 个 管理 Docker 和 集群 的 工具 ， 我 们 必须 首先 将 其 部 
署 于 某 一 节点 。Swarm 的 部 署 形式 比较 丰富 ,我们 可 以 将 其 部 署 于 物 
理 服务 器 上 ，, 也 可 以 将 其 部 署 于 虚拟 机 中 ， 还 可 以 将 其 部 署 在 Docker 


Ta LE 


容 莫 中 ，。 
由 于 Swarm 用 于 管理 Docker 和 集群 ， 因 此 我 们 自然 需要 一 个 或 者 


多 个 Docker 集 群 ， 集群 中 每 一 个 节点 均 安 装 并 运行 着 Docker。 具 体 
的 Swarm 架 构 如 图 15-1 所 示 。 






Strategy 


binpacking 


Docker Client 


15-1 Swarm 架构 


Swarm 染 构 中 最 主要 的 计算 部 分 是 Swarm 节 点 ,Swarm 管理 的 
对 象 自然 是 Docker Cluster ,Docker Cluster 由 多 个 Docker Node 
组 成 ， 而 负责 给 Swarm 发 送 请 求 的 是 Docker Client。 简 单 而 言 ， 
Swarm 与 Docker 一 样 ， 也 是 C/S 架 构 ，Client 为 Docker Client ， 
Server 是 Swarm 进程 。 以 下 主要 介绍 Swarm Node、Docker 


Node、node discovery 以 及 scheduler 这 4 个 重要 的 概念 。 


15.2.1 Swarm Node 


Swarm Node 可 以 认为 是 Swarm 的 主 控 节 点 ,角色 由 运行 的 
Swarm 程序 来 充当 。Swarm Node 正 常 运行 之 后 ， 该 节点 可 以 按 需 
完成 容器 调度 的 任务 ， 最 终 达 到 管理 Docker Node 集 群 的 效果 。 


一 般 情况 下 ， 用户 会 通过 添加 标签 ( label) 的 形式 ， 为 Docker 
Node 和 集群 中 的 每 一 个 节点 设置 角色 。 当 需要 调度 Docker 容 器 时 ， 
Swarm Node 根 据 用 户 需 求 以 及 所 有 Docker Node 的 角色 ， 决策 出 
最 佳 的 Docker Node 方 案 ， 并 将 容器 调度 至 该 Docker Node。 


为 完成 以 上 使 命 ，Swarm 的 设计 者 将 Swarm Node 设 计 成 多 个 
模块 的 形式 。 模 块 各 司 其 职 ， 并 有 机 结合 。Swarm 接 收 用 户 请 求 的 模 
块 暂 且 9 可 以 称 为 Server 模 块 ; 用 于 发 现 集群 中 Docker Node 的 模 
块 ， 我们 可 以 将 其 抽象 为 node discovery ; 收集 Docker Node 角 
色 ， 处 理 请 求 ， 调度 容 右 的 任务 则 最 终 落 在 scheduler 身 上 。 对 于 
Swarm 而 言 , scheduler 的 重要 性 不 言 而 喻 。 更 为 细 化 地 分 析 
scheduler , 可 以 发 现 sScheduler 内 部 还 有 负责 筛选 Docker Node 的 
filter 模 块 ， 以 及 在 筛选 后 的 集合 中 如 何 做 决策 的 Strategy 模块 。 


15.2.2 Docker Node 


Swarm 管理 Docker 集 群 ，Docker 集 群 则 由 一 个 或 多 个 Docker 
Node 组 成 。Docker Node 指 的 是 运行 Docker Daemon 的 计算 节 
点 。 对 于 Docker Node 而 言 ,只 要 有 足够 的 权限 操纵 Docker 
Daemon , 整个 Docker Node 的 容器 管理 能 力 就 被 掌控 。Swarm 
Node 就 利用 了 这 一 点 。Swarm 通 过 tcp 的 方式 ,访问 Docker Node 
监听 的 tcp 端 口 ， 从 而 控制 Docker Node。 原 则 上 ， 无 论 何 时 Docker 
管理 员 都 应 该 尽量 避免 Docker Daemon 监 听 tcp 端 口 ， 以 便 带 来 安 
全 隐患 。 特 殊 情 况 下 ， 应 该 在 TLS 协 议 的 保障 下 ， 开 启 Docker 
Daemon 的 tcp 监 听 问 口 。 


对 Docker Node 而 言 ,与 Swarm Node 建 立 联 系 是 其 融入 集群 
的 第 一 步 。 然 而 ， 这 还 不 够 ， 还 不 能 满足 用 户 容 硕 的 按 需 调度 。 为 实 
现 有 效 合理 的 容器 调度 功能 ， Swarm 建议 Docker Node 使 用 标签 的 
形式 来 标记 自身 的 Docker Daemon , 使 得 Swarm 获取 Docker 
Daemon 信 息 时 记录 Docker Node 的 角色 。 


15.2.3 node discovery 


node discovery 属 于 Swarm 架 构 中 的 服务 发 现 机 制 。 获 知 
Docker 和 集群 中 的 Docker Node 数量 以 及 每 个 Docker Node 具 体 的 信 
息 ,关乎 Swarm 的 管理 效率 以 及 集群 的 扩展 能 


服务 发 现 的 作用 很 明显 ， 只 有 向 Swarm Node 注 册 过 的 Docker 
Node 才 会 被 Swarm 划 入 Docker 集 群 范 畴 并 管理 。Swarm 提 供 多 种 
有 效 的 服务 注册 方式 ， 每 当 Docker Node 注 册 完 毕 之 后 , Swarm 有 
能 力 通过 注册 信息 与 Docker Node 上 的 Docker Daemon 进 程 建立 通 
信 ，, 实现 Docker Node 的 角色 信息 获取 等 。 


15.2.4 Scheduler 


scheduler 属 于 Swarm Node 的 调度 器 。 对 于 每 一 个 容器 的 调度 
请 求 ，scheduler 都 有 义务 为 其 确定 候选 的 Docker Node， 并 对 这 些 
Docker Node 按 照 用 户 指定 的 策略 进行 排序 。 目前 , Swarm 0.2.0 
中 ，scheduler 的 策略 有 三 种 : spread、binpack 以 及 random。 其 
中 ，spread 和 binpack 策 略 会 权衡 每 一 个 候选 Docker Node 的 可 用 
CPU 资 源 、 可 用 内 存 资 源 以 及 当前 Docker Node 上 运行 容器 的 数量 。 
而 random 则 简单 得 多 ， 该 策略 不 做 任何 计算 ， 仅 仅 随 机 挑选 一 个 候 


选 Docker Node。 


15.3 Swarm 命令 


通过 Swarm 架构 图 ， 大 家 可 以 对 Swarm 有 一 个 初步 的 认识 , 比 
如 Swarm 的 具体 工作 流程 : Docker Client 发 送 请 求 给 Swarm ; 
Swarm 处 理 请 求 并 发 送 至 相应 的 Docker Node ; Docker Node 执 行 
相应 的 操作 并 返回 响应 。 除 此 之 外 , Swarm 的 工作 原理 依然 还 不 够 明 
J 


深入 理解 Swarm 的 工作 原理 ， 可 以 先 从 Swarm 提 供 的 命令 入 
于 。Swarm 命 令 主要 有 4 个 : swarm create、swarm manage.、 
swarm join、swarm list。 当 然 ， 还 有 一 个 swarm help 命 令 ， 该 命 


令 有 助 于 正确 使 用 warm 命 令 ， 本章 不 再 获 述 。 


15.3.1 Swarm create 


Swarm 中 ,swarm create 命 令 用 于 创建 一 个 集群 标志 。 当 
Swarm 管 理 Docker 和 集群 时 ，Docker Node 通 过 这 个 全 球 唯一 的 集群 
标志 实现 节点 注册 功能 ,Swarm 通过 该 标志 发 现 集群 中 的 Docker 
Node。 


发 起 该 命令 之 后 ，Swarm 会 前 往 Docker Hub 上 内 建 的 服务 发 现 
中 获取 一 个 全 球 唯一 的 token， 用 于 唯一 地 标识 Swarm 管理 的 
Docker 和 集群 。 


Swarm 的 运行 需要 使 用 服务 发 现 ， 目 前 该 服务 内 建 于 Docker 
Hub ,该 服务 发 现 机 制 仍 处 于 alpha 版 本 ， 站 点 为 : 
http: /discovery-stage.hub/dockercom。 


15.3.2 Swarm manage 


Swarm 中 ,swarm manage 是 最 为 重要 的 管理 命令 。 一 旦 
swarm manage 命 令 在 Swarm Node 上 被 触发 ， 则 说 明 用 户 开始 使 
用 Swarm 管理 Docker 集 群 。 从 运行 流程 的 角度 来 讲 ，swarm 经 历 的 
阶段 主要 有 两 个 : 启动 swarm ,接收 并 处 理 Docker 集 群 管理 请 求 。 


Swarm 的 局 动 过程 包 含 三 个 步骤 : 


1) 发 现 Docker 集 群 中 的 各 个 Docker Node , 收集 节点 状态 、 
角色 信息 ， 并 监视 节点 状态 的 变化 ; 


) 初始 化 内 部 调度 笑 模 块 ; 
3) 创建 并 启动 API 监 听 服 务 模块 ; 


第 一 步 ，Swarm 发 现 Docker 和 集群 中 的 节点 。 发 现 
( discovery) 是 Swarm 中 用 于 维护 Docker 集 群 状 态 的 机 制 。 既 然 
涉及 发 现 ， 那 么 在 这 之 前 必须 先 有 注册 ( register) 。Swarm 中 有 专 
门 负 责 发 现 的 模块 ， 而 关于 注册 部 分 ， 不同 的 discovery 模 式 下 ，, 注 
册 也 会 有 不 同 的 形式 。 


目前 ,Swarm 中 提供 了 5 种 不 同 的 发 现 机 制 : Node 
Discovery、File Discovery、Consul Discovery、EtcD 


Discovery 和 Zookeeper Discovery。 


第 二 步 ，Swarm 内 部 的 调度 铸模 块 被 初始 化 。 当 swarm 通 过 发 
现 机 制 发 现 所 有 注册 的 Docker Node 并 收集 到 所 有 Docker Node 的 
状态 以 及 具体 信息 后 ， 一 旦 Swarm 接收 到 具体 的 Docker 管 理 请 求 ， 
Swarm 就 需要 对 请 求 进行 处 理 ， 并 通过 所 有 Docker Node 的 状态 以 
及 具体 信息 ,来 簿 选 决策 到 底 哪些 Docker Node 满 足 要 求 ， 并 通过 一 
定 的 策略 将 请 求 转发 至 具体 的 Docker Node。 


第 三 步 ， Swarm 创建 并 初始 化 API 监 听 服 务 模块 。 从 功能 的 角度 
来 讲 ， 可 以 将 该 模块 抽象 为 Swarm Server。 需 要 说 明 的 是 : 虽然 
Swarm Server 完 全 兼容 Docker 的 API , 但 是 有 不 少 Docker 命 令 目 
前 是 不 支持 的 ， 毕 竟 管 理 Docker 集 群 与 管理 单独 的 Docker 
Daemon 会 有 一 些 区 别 。 当 Swarm Server 初 始 化 完毕 并 完成 监听 之 
后 ， 用 户 即 可 以 通过 Docker Client 向 Swarm 发 送 Docker 和 集群 的 管 
理 请 求 。 


总 之 ,Swarm 的 swarm manage 接 收 并 处 理 Docker 集 群 的 管 
理 请 求 ， 这 也 是 Swarm 内 部 多 个 模块 协同 合作 的 结果 : 请 求 入 口 为 


Swarm Server , 处 理 引 擎 为 Scheduler , 节点 信息 Discovery 。 


15.3.3 Swarm join 


Swarm 的 swarm join 命令 用 于 将 Docker Node 添 加 至 Swarm 
管理 的 Docker 集 群 中 。 从 功能 上 出 发 ， 我 们 不 难 发 现 swarm join 命 
令 的 执行 位 于 Docker Node ,因此 在 Docker Node 上 运行 该 命令 ， 
首先 必须 安装 Swarm。 由 于 Docker Node 上 的 Swarm 只 可 能 执行 
swarm join 命令 ,故我 们 可 以 将 其 看 成 是 Docker Node 上 用 于 注册 
的 agent 模 块 。 


就 功能 而 言 ， 可 以 认为 Swarm join 完成 Docker Node 在 Swarm 
节点 处 的 注册 ( registen 工作 ,以 便 Swarm 在 执行 swarm 
manage 时 可 以 发 现 该 Docker Node。 然 而 ，15.3.2 节 提 及 的 5 种 
discovery 机 制 中 ， 并 非 每 种 机 制 都 支持 Swarm join 命令 。 不 支持 的 
discovery 机 制 有 Node Discovery 与 File Discovery。 


Docker Node 上 swarm join 命令 的 执行 ， 标 志 着 Docker Node 
向 Swarm 注册 。Swarm 通 过 注册 信息 ,发现 Docker Node， 并 获取 
Docker Node 的 状态 以 及 具体 信息 ， 以 便 处 理 Docker 请 求 时 作为 调 
度 依据 。 


15.3.4 Swarm list 


Swarm 中 的 Swarm list 命 令 用 于 列举 Docker 集 群 中 的 Docker 
Node。 


Docker Node 的 信息 均 来 源 于 Swarm 节点 上 注册 的 Docker 
Node。 而 一 个 Docker Node 在 Swarm 节点 上 仅仅 注册 了 Docker 
Node 的 IP 地 址 以 及 Docker Daemon 监 听 的 冯 间 号。 使 用 Swarm 
list 命 令 时 ， 需 要 指定 discovery 的 类 型 ， 类 型 包括 : token、etcd、 


file、zk 以 及 < ip> 。 


15.4 总 结 


Swarm 的 架构 以 及 命令 并 不 复杂 ， 本 章 初 步 介 绍 了 Swarm、 
Swarm 架构 的 设计 与 实现 以 及 Swarm 命令 ,希望 能 为 学 习 Docker 集 
群 化 管理 的 Docker 爱 好 者 带 来 帮助 。 


俗话 说 得 好 ,没有 一 种 一 劳 永 逸 的 工具 ， 有 效 地 管理 Docker 集 群 
同样 也 是 如 此 。 脱 离 场景 来 谈论 Swarm 的 价值 , 意义 并 不 会 很 大 。 相 
反 ， 探 索 和 挖掘 Swarm 的 特点 与 功能 ， 并 为 Docker 集 群 的 管理 提供 
一 种 可 选 的 方案 ， 则 是 Docker 爱 好 者 更 应 该 参与 的 事 。 


第 16 章 Machine 架构 设计 与 实现 
16.1 引言 


2014 年 12 月 ，Docker 官 方 在 荷兰 举办 的 DockerCon 大 会 上 宣 
布 推出 Docker Machine。 此 举 预 示 着 Docker 从 原先 的 单机 部 署 迈 向 
集群 部 署 ，Docker 生 态 圈 的 能 力 更 上 一 层 楼 。 


Docker 毕 竟 还 是 一 个 正在 飞速 成 长 的 项 目 ， 尽 管 存在 琉 兹 ,但 是 
Docker 在 单机 上 的 能 力 已 经 征服 大 量 优秀 的 开发 者 。 随 着 数 十 年 来 分 
布 式 系统 的 发 展 ， 分 布 式 领域 同样 对 Docker 有 着 非常 强烈 的 诉求 。 如 
何在 服务 器 上 自动 化 部 署 Docker , 如 何 跨 宿 主机 部 署 ， 如 何 使 
Docker 的 部 署 适 应 不 同 的 基础 设施 环境 ， 都 会 是 Docker 在 分 布 式 生 
产 环境 中 落地 时 必须 考虑 的 因素 。 


正 是 在 如 此 背景 下 , Machine 应 运 而 生 。Machine 使 得 Docker 
的 部 闭 异 常 简易 ， 不 论 是 用 户 的 单个 主机 ， 还 是 用 户 的 数据 中 心 ， 以 
及 可 能 是 第 三 方 云 平台 提供 商 提供 的 云 主 机 。Machine 可 以 帮助 用 户 
在 运行 环境 中 创建 虚拟 机 服务 节点 ， 在 虚拟 机 中 安装 并 配置 Docker ， 
最 终 帮 助 用 户 配 置 Docker Client , 使 得 Docker Client 有 能 力 与 虚拟 
机 中 的 Docker 建 立 通信 。 


一 个 大 型 的 分 布 式 环境 中 ，Docker 集 群 的 从 无 到 有 ，Machine 
甚至 可 以 一 键 完 成 ， 这 无 疑 将 大 大 节省 运 维 团队 的 人 力 、 物 力 。 同 
时 ，Machine 完 全 有 能 力 适 应 多 种 不 同 的 底层 基础 设施 ， 如 
OpenStack、VirtualBox、Amazon EC2、Azure、Rackspace、 
DigitalOcean、SoftLayer、HyperV 等 一 系列 国际 知名 基础 设施 提 
供 平 台 。 另 外 ,通过 Machine 创 建 的 虚拟 机 ， 不 仅 已 经 完成 Docker 
的 安装 与 配置 ， 同 时 还 可 以 保证 环境 中 所 有 Docker 配 置 的 一 致 性 。 只 
要 是 通过 Machine 创 建 并 部 闭 的 Docker 节 点 ，Machine 就 能 对 其 进 


行 远 程 管理 或 者 执行 Docker 命 邻 。 


全 球 范 围 内 ， 随 着 基础 设施 即 服 务 ( laaS) 越 来 越 完善 以 及 
Docker 的 逐渐 成 熟 ， 大 型 分 布 式 环境 中 Docker 的 集群 化 部 著 与 配 
置 ,是 一 个 必须 攻克 的 问题 。Machine 作 为 Docker 官 方 推荐 的 部 署 
工具 ， 深 度 关 注 与 学 习 Machine 将 变 得 意义 重大 。 


16.2 ” Machine 架构 


Machine 可 以 帮助 用 户 通过 一 条 命令 ， 从 零 开 始 ， 在 极 短 的 时 间 
内 ， 拥 抱 Docker。 为 实现 此 目标 ， 用 户 需要 准备 一 些 前 提 条 件 ， 如 安 
装 Machine 软 件 ( docker-machine) 、 提 供 第 三 方 的 虚拟 机 、 提 供 
软件 或 基础 设施 平台 。 


Machine 软 件 可 以 通过 下 载 二 进 制 文件 获取 ，Docker 官 方 的 下 载 
地 址 为 : http://docs.docker.com/machine/。 官 方 提 供 的 版 本 可 以 
支持 三 种 操作 系统 ， 即 Windows、OSX 以 及 Linux。 除 此 之 外 ， 用 户 
可 以 通过 编译 Machine 的 源码 生成 Machine 二 进 制 文件 , Machine 的 
源 代 码 完全 托管 于 Github， 地 址 为 
https://github.com/docker/machine, 目前 ,Machine 仍 然 处 于 
Beta 版 本 ， 功能 以 及 特性 都 还 在 不 断 地 变化 中 ， 因 此 Docker 官 方 暂时 
还 不 建议 将 Machine 运 用 于 生产 环境 。 Machine 的 版 本 更 新 非常 迅 
速 ， 本 章 以 Machine v0.2.0 为 例 ,分 析 Machine 的 架构 以 及 实现 。 


Machine 的 架构 设计 如 图 16-1 所 示 。 
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图 16-1 Machine 架 构图 


并 非 如 Docker 一 般 ，Machine 不 是 一 个 Client/Server 架 构 。 用 
户 通过 dockermachine 命 令 使 用 Machine 时 ， 后 台 并 非 是 一 个 常 驻 
的 服务 进程 。 实 际 情况 下 , 每 次 dockermachine 命 令 被 触发 时 ， 系 
统 都 会 创建 一 个 相应 进程 来 完成 用 户 指定 的 任务 ， 任 务 完成 后 进程 随 
即 退出 。 由 于 Machine 并 没有 后 台 进 程 ， 故 通过 内 存 来 存储 数据 的 方 
式 也 将 行 不 通 ， 此 时 Machine 将 所 有 创建 的 虚拟 机 信息 以 及 Docker 信 
息 持 久 化 至 宿主 机 文件 系统 中 。 


为 了 更 好 地 理解 Machine 的 架构 ， 首先 我 们 来 认识 Machine 中 的 
几 个 重要 的 概念 : Machine、Store、Host、Driver 以 及 


Provisioner, 


16.2.1 Machine 
此 Machine 并 非 代 表 Machine 软 件 ， 也 不 指 代 dockermachine 
二 进 制 文件 ， 而 是 软件 实现 过 程 中 抽象 出 的 一 个 数据 结构 。 


对 于 docker-machine create 命 令 而 言 ， 一 个 Machine 对 象 会 


创建 ， 然 后 所 有 与 该 Machine 相 关 的 信息 都 存储 到 指定 的 路 径 中 。 


16.2.2 Store 


对 于 每 一 个 创建 的 Machine 对 象 ， 相 应 的 元 数据 都 会 被 持久 化 到 
本 地 文件 系统 中 ，Store 则 用 于 告知 用 户 这 些 元 数据 的 存储 位 置 。 
Store 类 型 包含 三 个 属性 : root、caCertPath、privateKeyPath。 
属性 root 代 表 Machine 对 象 信 息 存储 的 根 目 录 ; caCertPath 代 表 连 
接 Machine 所 需 证 书 的 路 径 ; 而 privateKeyPath 则 代表 通过 ssh 连 接 
虚拟 机 时 私 钥 所 在 路 径 。 


16.2.3 Host 


Host 代 表 通 过 Machine 在 相应 的 基础 设施 上 创建 的 虚拟 机 。 每 一 
个 Host 对 象 都 包含 Machine 管 理 一 台 虚 拟 机 所 需要 的 所 有 信息 。 这 些 
言 息 包 括 虚 拟 机 名 称 ( Name) 、 连 接 基础 设施 的 driver 名 称 
( DriverName) 、 有 具体 的 Driver 对 象 ( _ Driven 、 存 储 Machine 实 
例 所 有 信息 的 路 径 ( StorePath) 、 包 含 Host 具 体 信息 的 选项 
( HostOptions) ， 另 外 还 有 与 Swarm 相关 的 信息 以 及 认证 内 容 。 


值得 一 提 的 是 HostOptions ,其 携带 的 虚拟 机 信息 都 在 整个 
Machine 中 扮演 重要 角色 。 首 先 ， 包 括 虚拟 机 的 内 存 大 小 、 磁 盘 大 
小 。 另 外 , HostOptions 的 EngineOptions 属 性 携带 虚拟 机 中 
Docker Daemon 的 配置 信息 ,包括 : DNS 配置 、 镜 像 存 储 driver、 
Daemon Label 等 众多 配置 信息 ; SwarmOptions 属 性 代表 是 否 为 该 
虚拟 机 中 创建 一 个 Swarm 节点 ; AuthOptions 则 是 认证 信息 ， 用 于 建 
立 用 户 与 Docker Daemon 之 间 的 通信 。 抽 象 Machine 源 码 ,归纳 总 
结 出 的 Host 数 据 结构 如 图 16-2 所 示 。 
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图 16-2 Host 数据 结构 


16.2.4 Driver 


Driver 在 Machine 中 起 到 承前启后 的 作用 ， 承 前 的 是 : 所 有 创建 
虚拟 机 的 请 求 ， 最 终 都 需要 落实 到 指定 的 Driver 层 ; 启 后 的 是 : 
Driver 向 具体 的 基础 设施 发 起 虚拟 机 创建 请 求 ， 基 础 设施 的 响应 也 将 
首先 返回 至 Driver。 


16.1 节 提 到 ,Machine 目 前 支持 众多 的 基础 设施 供应 商 。 如 此 一 
来 ， 由 于 不 同 基础 设施 平台 之 间 存 在 对 外 接口 的 差异 性 ，Machine 很 
难 做 到 提供 一 个 大 而 全 的 Driver ,涵盖 所 有 基础 设施 ,因此 Machine 
中 Driver 的 种 类 会 与 基础 设施 一 一 对 应 。 事 实 的 确 如 此 ， 对 于 不 同 的 
基础 设施 ,Machine 使 用 不 同 的 Driver 来 完成 任务 ，openstack 
driver 则 完全 适 配 OpenStack 平 台 的 接口 ， 完 成 OpenStack 平 台 上 
虚拟 机 的 创建 ; 对 于 VirtualBox 这 种 虚拟 化 技术 ，Machine 采 用 
virtualbox driver ,进而 使 用 VBoxManage 管 理工 具 完成 
VirtualBox 下 虚拟 机 的 申请 .…… 


16.2.5 Provisioner 


Driver 完 成 的 工作 是 : 在 基础 设施 平台 上 从 无 到 有 创建 虚拟 机 。 
然而 ， 整 个 过 程 中 并 不 涉及 Docker、Docker Daemon 的 内 容 ， 换 
言 之 ,创建 虚拟 机 之 后 ,虚拟 机 中 并 没有 安装 Docker。Provisioner 
对 象 则 起 到 这 最 后 一 块 拼图 的 作用 。 


Machine 的 使 命 就 是 在 裸 环境 中 创建 装 有 Docker 的 机 郑 ， 并 统 
一 化 管理 。 因 此 ， 通 过 Driver 创 建 虚 拟 机 之 后 ，Provisioner 完 成 
Docker 安 装 与 配置 的 任务 。 不 同 虚 拟 机 有 可 能 操作 系统 类 型 不 同 ， 而 
操作 系统 不 同 ，Provisioner 及 取 的 手段 也 不 同 。 目前 ，Machine 仪 
仪 支 持 两 种 操作 系统 发 行 版 的 Docker 安 装 ， 分 别 为 Ubuntu 和 
boot2docker。 


一 次 完整 的 Provision 流 程 ， 包 含 以 下 5 个 步骤 : 
1) 为 虚拟 机 设置 主机 名 hostname ; 
2) 若 虚 拟 机 中 没有 安装 Docker , 则 为 其 安装 Docker ; 


3) 配置 Docker Daemon 参数, 使 其 局 动 后 仅仅 接受 TLS 连 接 ; 


4) 复制 证 书 至 本 地 Machine 实 例 的 目录 ,并 上 传 证 书 以 及 TLS 
认证 信息 至 虚拟 机 ; 


5) 若 用 户 指定 Machine 与 Swarm 的 结合 ， 通过 Docker 启 动 
Swarm 容器 ， 并 对 其 进行 配置 。 


16.2.6 ”Machine 运 行 流程 


清楚 Machine 中 重要 的 概念 之 后 ， 我 们 一 起 进入 Machine 的 运行 
流程 一 探究 竟 。 回 到 图 16-1 的 Machine 架 构图 中 ， 假 设 现在 用 户 的 需 
求 是 : 在 OpenStack 平 台 上 创建 一 台 虚 拟 机 ， 虚拟 机 的 操作 系统 为 
Ubuntu , 并 且 虚 拟 机 中 必须 安装 有 Docker。 我 们 以 此 为 例 ,分析 


Machine 的 运行 流程 。 


Machine 的 运行 流程 主要 围绕 Machine、Host、Provisioner 展 
开 ,如 下 : 


) 用 户 通过 dockermachine 运 行 用 户 命令 。 该 命令 中 必须 要 
包含 openstack driver 的 名 称 ， 以 及 为 所 创建 虚拟 机 指定 的 名 称 ， 命 


令 的 示例 如 下 : docker-machine create-d openstack dev...... 


2) Machine 解 析 Create 人 命令， 配置 Store 参 数 ,检测 driver 绽 
型 ， 创 建 Machine 对 象 ， 并 配置 hostOptions 参 数 ; 


3) Machine 通 过 虚拟 机 指定 的 名 称 ， 用 户 指定 的 driver ,以 及 
虚拟 机 配置 信息 hostOptions 创 建 Host 对 象 ; 


4) Machine 将 创建 的 虚拟 机 设置 为 active 状 态 。 


以 上 四 个 环节 中 ， 创建 Host 的 环节 涉及 内 容 最 多 。Machine 创 建 
虚拟 机 首先 需要 获知 driver 类 型 ， 即 用 户 需 要 在 哪 种 基础 设施 平台 上 
创建 。 解 析 -d 参 数 ， 仅 仅 获 取 driver 类 型 openstack 还 还 远 不 够 ， 用 
户 还 需要 指定 与 openstack 平 台 相 关 的 诸多 信息 ， 如 代表 
OpensStack 认 证 URL 的 OS_ AUTH_URL , OpenStack 的 用 户 名 
OS_USERNAME 和 密码 O0S PASSWORD , OpenStack 平 台中 镜像 
的 ID“openstack-image-id" 等 。 由 于 前 面 假 设 通过 Machine 创 建 
Ubuntu 虚拟 机 ，, 故 指定 ID 所 代表 的 镜像 应 该 为 Ubuntu 操作 系统 。 


OpenStack driver 解 析出 所 有 参数 之 后 ， 通 过 driver 内 置 的 
openstack client 向 基础 设施 平台 发 起 虚拟 创建 请 求 。 创 建 完 毕 之 
后 ,也 是 Provisioner 登 场 之 时 。Provisioner 的 第 一 个 任务 便 是 获悉 
虚拟 机 内 部 的 操作 系统 发 行 版 类 型 ( Ubuntu 或 者 boot2docken 
实现 方式 为 : 通过 SSH 远 程 登录 虚拟 机 ， 并 查看 /etc/os-realease 的 
内 容 ， 以 此 判断 操作 系统 发 行 版 的 类 型 。 类 型 的 确定 ， 意 味 着 
Provisioner 可 以 对 虚拟 机 实行 有 针对 性 的 Docker 安 装 计划 ， 有 具体 可 


以 参见 前 面 Provisioner 的 执行 流程 。 


完成 虚拟 机 的 创建 ， 完 成 Docker 的 安装 ， 原 则 上 来 讲 ， 创 建 工作 
已 经 完成 。 然 而 ， 为 了 让 用 户 方便 地 使 用 新 创建 的 Docker ， 


Machine 可 以 通过 命令 eval"$( docker-machine env dev) " ,使 


得 本 地 的 Docker Client 无 需 显 式 指定 即 可 连接 远程 的 Docker 


Daemon。 


16.3 ” Machine 与 Swarm 的 结合 


Machine 在 Docker 体 系 中 的 作用 是 : 创建 装 有 Docker 的 虚拟 
机 。 通 过 Machine 强 大 的 部 效能 力 ， 我 们 并 不 能 很 好 地 调度 和 管理 
Docker 集 群 。 而 Swarm 的 作用 正 是 为 Docker 集 群 进行 有 效 的 管理 与 
调度 ， 若 能 将 Machine 与 Swarm 有 效 结合 ， 必 能 为 Docker 集 群 的 管 
理 人 员 带 来 巨大 的 便利 。 


Machine 的 设计 理念 则 充分 考虑 了 这 一 点 。 只 要 用 户 有 需求 ， 
Machine 就 完全 有 能 力 在 虚拟 机 中 安装 Docker 时 ， 通 过 Docker 
Daemon 有 启动 一 个 Swarm Master 节 点 ， 用 来 管理 其 余 的 Docker 
Node。 当然 ，Machine 也 可 以 在 安装 Docker 时 ， 启动 一 个 Swarm 
Agent 容 器 ， 并 将 Docker Daemon 作 为 一 个 Docker Node 注册 到 指 
定 的 Swarm Master 中 ，, 便于 Swarm Master 后 续 对 于 该 Docker 
Node 的 调度 。Swarm Master 并 未 直接 运行 在 虚拟 机 中 ， 而 是 运行 在 
Docker 容 闫 中 。Machine 与 Swarm 的 关系 如 图 16-3 所 示 。 
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图 16-3 Machine 与 Swarm 的 关系 


关于 如 何在 虚拟 机 上 安装 并 配置 Docker , 16.2 节 已 经 讲述 得 较为 
清晰 。 事 实 上 ,Swarm 的 引入 完全 是 在 此 基础 上 完成 的 。 由 于 Swarm 
的 运行 环境 为 Docker 容 闫 , 故 Swarm 的 局 动 离 不 开 Docker。 实 际 运 
行 过 程 也 是 如 此 ， 若 用 户 指定 安装 Swarm， 则 Machine 首 先 通过 
Provisioner 在 虚拟 机 中 安装 Docker ,并 在 Provisioner 安 装 与 配置 的 


最 后 一 个 步 又 执行 ConfigureSwarm ，, 完成 Swarm 的 启动 。 


若 需 要 配置 Swarm , 不 论 是 Swarm Master 还 是 Swarm 
Agent ,用 户 均 需 在 执行 docker-machine create 命 令 时 传 入 相应 的 


参数 。 


首先 来 看 Swarm Master 的 配置 流程 。Docker 安 装 完毕 之 后 ， 
Machine 中 的 Porvisioner 模 块根 据 用 户 的 需求 ， 需 要 在 虚拟 机 上 配置 
Swarm Master , 故 Provisioner 通 过 SSH 连 接 至 虚拟 机 中 ， 并 执行 
docker pull swarm : latesti 请 求 ， 用 于 下 载 swarm 镜 像 。 值 得 一 提 
的 是 ,swarm 镜 像 不 仅 可 以 用 来 局 动 Swarm Master , 同样 可 以 用 来 
月 动 Swarm Agent。 由 于 用 户 指定 局 动 Swarm Master , 故 
Provisioner 又 执行 docker run swarm : latest manage...... 命令 ， 


直接 启动 Swarm Master , 并 管理 传 入 的 Docker Node。 


一 般 而 言 ， 一 旦 用 户 要 求 配置 Swarm ，, 不论 配置 Swarm Master 
还 是 Swarm Agent , 虚拟 机 都 会 配置 Swarm Agent， 并 受到 Swarm 
Master 的 管理 。 如 此 一 来 ， 会 出 现 Swarm Master 与 Swarm Agent 
处 于 同一 个 Docker Node 上， 而 这 种 情况 其 实 并 不 矛盾 ,Swarm 
Master 也 可 以 很 好 地 管理 自身 所 在 的 Docker Daemon。 对 于 Swarm 
Agent 的 配置 ，Provisioner 则 执行 docker run swarm : latest 


join...... 命令 ， 使 得 Swarm Agent 注 册 到 指定 的 Swarm Master。 


Swarm Master 与 Swarm Agent 的 配置 完毕 ， 则 意味 着 Swarm 
集群 的 成 功 创建 。Machine 的 存在 很 大 程度 上 降低 了 用 户 与 基础 设施 
打交道 的 成 本 ， 从 0 到 1 快速 创建 Swarm 集群 。 


16.4 总 结 


面 对 大 型 分 布 式 环境 或 者 尚未 利用 的 基础 设施 ， 如 何 快速 、 有 
效 、 方 便 地 使 用 Docker , 已 经 不 再 是 一 个 脱离 现实 的 问题 。 某 种 程度 
上 讲 ，Machine 的 诞生 使 得 Docker 技 术 的 普及 超越 了 开发 者 的 单机 
模式 ， 更 是 为 中 大 型 企业 大 规模 运用 Docker 提 供 了 可 能 性 。 


然而 ， 对 于 不 同 的 场景 ， Machine 的 价值 也 不 尽 相 同 ,快速 创建 
Docker 并 分 发 虚拟 机 的 模式 ， 在 大 规模 的 开发 环境 下 ， 能 为 开发 者 带 
来 很 大 的 价值 。Machine 与 Swarm 甚至 其 他 容器 调度 引擎 的 结合 ， 
更 是 为 大 规模 集群 的 管理 与 调度 提供 了 莫大 的 参考 价值 。 另 外 ， 
Machine 对 多 基础 设施 的 支持 ， 同 样 大 大 降低 了 云 平 台 迁 移 的 难度 ， 
为 混合 云 的 发 展 ， 提 供 强 有 力 的 事实 依据 。 


第 17 革 Compose 染 构 设 计 与 实现 
17.1 引言 


众所周知 ， 随 着 不 断 地 发 展 与 完善 ，Docker 的 API 接 口 变 得 越 来 
越 多 。 尤 其 在 容器 参数 的 配置 方面 ， 功 能 的 完善 势必 造成 参数 列表 的 
增长 。 若 在 Docker 的 范畴 内 管理 容 磊 ， 则 唯一 的 途径 是 使 用 Docker 
Client。 而 Docker Client 最 原生 的 使 用 方式 是 : 利用 docker 二 进 制 
文件 发 送 命令 行 命令 。 一 些 特 殊 的 应 用 场景 下 ， 容 器 管理 过 程 的 配置 
项 极为 见长 ， 甚 至 很 可 能 是 多 容 次 的 环境 。 因 此 ， 通 过 命令 行 来 完成 
容 厂 管理 显然 不 是 长 久之 计 。 很 长 一 段 时 间 内 ,全球 的 Docker 爱 好 者 
都 在 探索 以 及 寻找 方便 容器 部 署 的 途径 。 


Docker 诞 生 于 2013 年 3 月 ， 同 年 2 月， 基于 Docker 容 器 的 部 署 
工具 Fig 隆 重 登场 。 在 Docker 生 态 圈 中 ， 经 过 了 两 年 多 的 洗礼 ，Fig 项 
目 得 到 飞速 发 展 的 同时 ， 背后 的 东家 也 发 生 了 很 大 的 变化 。 作 为 
Docker 界 容 妖 自动 化 部 署 工具 的 瓯 楚 ，Fig 原 本 是 英国 伦敦 一 家 创业 
型 公司 的 产品 。 随 着 产品 的 发 展 ，Fig 的 巨大 潜力 受到 工业 界 的 普遍 认 
可 ， 在 不 到 一 年 的 时 间 内 就 受到 Docker 公 司 的 密切 关注 。 很 快 就 在 
2014 年 7 月 双方 爆 出 新 闻 : Docker 收 购 Fig。 收 购 完成 之 后 ，Fig 改 名 


为 Compose ,命令 改 为 dockercompose。 


17.2 Compose 介 绍 


探听 Fig 与 Compose 的 前 世 今 生 之 后 ， 让 我 们 回 到 Compose 本 
身 ， 尝 试 挖掘 Compose 如 何在 Docker 和 再 世 中 皆 圳 头角， 尝试 分 析 
Compose 的 技术 以 及 定位 又 是 如 何 。 


认识 一 样 新 事物 ， 从 新 事物 的 作用 入 手 ， 往 往 不 会 出 太 大 差错 。 
而 Compose 最 大 的 作用 ， 就 是 帮助 用 户 缓解 甚至 解决 容器 部 署 的 复 
杂 性 。 最 原始 的 情况 下 ， 通 过 Docker Client 发 送 容器 管理 请 求 ， 尤 
其 是 docker run 命 令 ， 一旦 参数 数量 又 增 ， 通过 命令 行 终端 来 配置 容 
右 较 为 耗 时 ， 同 时 容错 性 较 差 ， 且 修复 错误 命令 的 时 间 成 本 很 高 。 
Compose 则 将 所 有 容器 参数 通过 精简 的 配置 文件 来 存储 ， 用 户 最 终 
通过 简短 有 效 的 dockercompose 命 令 管理 该 配置 文件 ， 完 成 
Docker 容 怖 的 部 闭 。 


编辑 配置 文件 与 编辑 命令 行 命 令 的 难 易 程 度 高 下 立 判 。 同 时 配置 
文件 数据 的 结构 化 程度 越 高 ， 可 读 性 也 会 越 强 。 传 统 情 况 下 ， 如 
docker run 等 命令 的 参数 数量 很 多 时 ， 由 于 flag 参 数 的 书写 格式 各 
异 ， 很 容易 造成 用 户 费解 的 情况 ; 而 配置 文件 中 一 行内 容 就 是 一 类 具 
体 的 参数 值 ， 可 读 性 大 大 增强 。 


在 生产 环境 下 ，Docker Client 还 有 一 方面 经 常 被 Docker 爱 好 者 
所 庆 病 ， 那 就 是 难以 进行 多 容 莫 的 管理 ， 每 次 管理 的 容 颖 对 象 最 多 只 
能 是 1 个 。 容 痪 虽然 运行 时 相对 非常 独立 ， 但 是 很 多 情况 下 ， 容 怖 之 
间 会 存在 逻辑 关系 ， 如 容器 A 使 用 容 疾 B 的 data volume ,如 容 希 C 需 
要 对 容 希 D 执 行 link 操 作 等 。 对 于 有 逻辑 关联 的 容 右 ， 如 果 能 将 其 作 
为 一 个 整体 ， 被 工具 统一 化 管理 ， 那 将 大 大 减少 用 户 的 人 为 参与 ， 提 
高 部 著 效 率 。 


诱 人 的 功能 与 软件 的 完美 之 间 ， 往 往 不 能 男 等 号 ，Compose 同 
样 如 此 。 毕 竟 Compose 的 调用 对 象 为 Docker , 故 Docker 的 发 展 将 
直接 影响 到 Compose 的 未 来 。Docker 滑 且 还 没有 达到 完美 的 地 方 ， 
更 从 论 Compose ,因此 Docker 官 方 并 不 建议 Compose 爱 好 者 在 生 
产 环 境 中 使 用 该 工具 。 除 此 之 外 ，Compose 本 身 也 存在 一 些 缺 陷 ， 
不 剖 悉 其 本 质 ,自然 也 会 深 陷 其 中 ， 难 以 脱身 ，。 


Compose 软 件 的 开发 绝 大 部 分 通过 Python 语言 完成 ， 而 本 章 的 
分 析 均 基于 Compose 1.2.0 版 本 。 


17.3 Compose 架 构 


Docker 生 仿 圈 中 ，Compose 扮 演 的 是 部 著 工 具 的 角色 。 用 户 使 
用 Compose 时 ， 首 先 需要 将 部 著 意 图 通过 配置 文件 的 形式 交 给 
Compose。 这 样 的 配置 需求 包括 : 容 怖 的 服务 名 、 容 需 镜 像 的 build 
路 径 、 容 旨 运 行 环境 的 配置 等 。 以 下 是 一 个 较为 简单 的 Compose 配 置 
文件 。 此 配置 文件 定义 了 两 个 服务 ， 名 称 分 别 为 web 以 及 db。 服 务 
web 的 镜像 可 以 通过 docker build 来 构建 ，Dockerfile 所 处 目录 为 该 
配置 文件 当前 目录 ; 服务 web 需 要 对 db 服务 进行 link 操 作 ; 最 终 服务 
web 将 答 主 机 上 的 8000 端 口 映 射 到 容 北 内 部 的 8000 妆 口 。 服 务 db 通 
过 镜像 postgres 来 创建 。 


web : 
build: . 
links: 
- db 


ports : 
- "8000:8000" 
db: 


image: postgres 


配置 文件 在 Compose 体 系 中 不 可 或 缺 。Fig 时 代 支 持 的 配置 文件 
名 为 fg.yml 以 及 fig.yaml ; 为 了 兼容 遗留 的 Fig 化 配置 ,目前 
Compose 支 持 的 配置 文件 类 型 非常 丰富 ， 主 要 有 以 下 5 种 : fg.yml、 
fig.yaml、dockercompose.yml、dockercompose.yaml 以 及 用 


户 指定 的 配置 文件 路 径 。 


配置 文件 的 存在 为 Compose 提 供 了 容 疮 服务 的 配置 信息 ， 在 此 基 
础 上 ,Compose 通 过 不 同 的 命令 类 型 ,将 用 户 的 docker-composer 
命令 请 求 分 发 到 不 同 的 处 理 方法 进行 相应 的 处 理 。 用 户 docker- 
compose 的 命令 类 型 有 很 多 ， 如 命令 请 求 docker-compose up...... 
的 类 型 为 up 请 求 ，Compose 将 up 请 求 分 发 至 隶属 于 up 的 处 理 方法 来 
处 理 ; 命令 请 求 docker-compose run...... 的 类 型 为 run ,Compose 


将 run 请 求 分 发 至 隶属 于 run 的 处 理 方法 来 处 理 。 


对 于 不 同 的 dockercompose 请 求 ,Compose 将 调用 不 同 的 处 理 
方法 来 处 理 。 由 于 最 终 的 处 理 必 须 落 实 到 Docker Daemon 对 容 冀 的 
部 署 与 管理 上 ， 故 Compose 最 终 必 须 与 Docker Daemon 建 立 连 接 ， 
并 在 该 连接 之 上 完成 Docker 的 API 请 求 。 事 实 上 , Compose 借 助 
dockerpy 来 完成 此 任务 。dockerpy 是 一 个 使 用 Python 开发 并 调用 
Docker DaemonAPI 的 Docker Client 包 。 需 要 说 明 的 是 ， 毕 竟 
docker-py 作 为 Docker 官 方 的 一 个 Python 软 件 包 , 和 Docker 并 不 隶 
属于 同一 个 项 目 ， 因 此 dockerpy 在 很 多 方面 的 发 展 均 会 浪 后 于 
Docker , 即 理论 上 而 言 ,dockerpy 支 持 的 API 接 口 理论 上 会 比 
Docker Daemon 原 生 支 持 的 API 接 口 要 少 。 因 此 , 当 使 用 dockerpy 
作为 Docker Client 访 问 Docker Daemon 时 ,确定 API 版 本 的 支持 是 
非常 有 必要 的 一 步 。 另 一 方面 ,在 dockerpy 支 持 的 Docker API 接 口 
之 中 ，Compose 也 并 没有 对 其 进行 百分之百 的 实现 ， 而 这 主要 受 限 于 
Compose 自 身 的 软件 定位 。 


清楚 Compose 的 配置 文件 、 处 理 方 法 以 及 dockerpy 概 念 之 后 ， 
再 来 分 析 Compose 的 架构 ， 如 图 17-1 所 示 。 


在 Compose 染 构 中 , 我们 可 以 发 现 三 个 新 的 部 分 ,分别 为 : 
project、service 以 及 container。 这 三 个 概念 均 为 Compose 抽 象 的 
数据 类 型 ， 其 中 project 会 包含 service 以 及 container。 首 先 介 绍 这 三 


者 的 意义 。 


project 代 表 用 户 需 要 完成 的 一 个 项 目 。 何 为 项 目 ? Compose 的 
一 个 配置 文件 可 以 解析 为 一 个 项 目 ， 即 Compose 通 过 分 析 指 定 配置 文 
件 ， 得 出 配置 文件 所 需 完 成 的 所 有 容 奖 管理 与 部 署 操作 。 例 如 : 用 户 
在 当前 目录 下 执行 dockercompose up-d , 配置 文件 为 当前 目录 下 的 
配置 文件 docker-compose.yml , 命令 请 求 类 型 为 up，-d 为 命令 参 
数 ， 对 于 配置 文件 中 的 内 容 ,， Compose 会 将 其 解析 为 一 个 project。 
一 个 project 拥 有 特定 的 名 称 ， 并 且 包 含 多 个 或 一 个 service ,同时 还 


带 有 一 个 Docker Client。 


Service ,代表 配置 文件 中 的 每 一 项 服务 。 何 为 服务 ? 即 以 容 需 为 
粒度 , 用户 需要 Compose 所 完成 的 任务 。 再 次 以 本 节 前 面 配置 文件 为 
例 ， 配 置 文件 中 共 包 含 了 两 个 service , 第 一 个 名 为 web， 第 二 次 名 为 
db。 一 个 service 包 含 的 内 容 ， 无 非 是 用 户 对 服务 的 定义 。 定 义 一 个 服 
务 ， 可 以 为 服务 容 郑 指定 镜像 ， 设 定 构建 的 Dockerfile , 可 以 为 其 指 
定 link 的 其 他 容 希 ， 还 可 以 为 其 指定 端口 的 映射 等 。 
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图 17-1 Compose 架 构 


从 配置 文件 到 service， 实 现 了 用 户 语义 到 Compose 语 义 的 转 
换 。 虽 然 一 个 service 尽 可 能 详细 地 描述 了 一 个 容 殿 的 具体 信息 ， 但 是 
Compose 并 一 定 必须 在 service 之 上 管理 容 希 ， 如 果 用 户 使 用 
docker-compose pull db 命令 ， 则 仅仅 完成 db 服务 中 指定 镜像 的 下 
载 。 除 此 之 外 , Compose 的 service 还 可 以 映射 到 多 个 容 展 ， 如 采用 


户 使 用 docker-compose scale web= 3 命令 ， 则 可 以 将 web 服 务 横 
向 扩展 到 3 个 容 姨 。 


若 用 户 对 service 的 请 求 最 终 会 落实 到 一 个 具体 的 容 匿 上 ， 则 
Compose 会 在 service 范 畴 内 创建 一 个 container 对 象 ， 完 成 对 具体 
容器 的 管理 。container 对 象 初始 化 时 即 集成 了 service 的 Docker 
Client， 最终 容器 所 有 的 操作 ， 都 由 container 对 象 通过 调用 Docker 
Client 完 成 。 


读 到 这 里 ， 大 家 可 能 会 一 个 疑惑 : Compose 如 何 决 策 所 有 
service 的 执行 顺序 ?如果 Compose 一 味 按照 配置 文件 中 的 书写 顺序 
来 完成 service 的 指定 任务 ， 显 然 会 出 现 一 些 不 可 避免 的 问题 。 假 设 多 
个 service 所 描述 的 容器 之 间 存 在 依赖 关系 ， 一旦 配置 文件 中 的 顺序 与 
实际 的 正常 启动 顺序 不 一 致 ， 必 将 导致 容器 局 动 失败 。 若 在 配置 文件 
中 容 希 A 的 描述 位 于 容 希 B 之 前 ， 而 容 益 A 的 局 动 叉 依赖 于 容 希 B， 此 时 
若 顺 序 执行 A、B ，A 容 闫 的 局 动 必定 将 失败 ， 而 之 后 B 容 问 可 以 正常 局 
动 。 


一 般 而 言 ， 容 郑 依 赖 关 系 会 存在 以 下 三 种 情况 : 存在 links 参 数 ， 
容 希 的 月 动 需 要 链接 到 另 一 个 容 硕 ; 存在 volumes from 参数 ， 容 关 
的 局 动 需要 挂 载 另 一 个 容 硕 的 data volume ; 存在 net 参 数 ， 容 莫 的 
局 动 过 程 中 网 络 模式 米 用 other container 模 式 ， 使 用 另 一 个 容 益 的 网 
络 栈 。 为 了 解决 这 些 问题 ， 对 于 用 户 的 某 些 请 求 ， 如 docker- 


] 
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] 
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compose up 等 ,Compose 在 解析 出 所 有 service 之 后 ， 需 要 根据 各 
service 的 定义 情况 ， 梳 理 出 所 有 的 依赖 关系 ， 并 最 终 以 一 个 没有 冲突 
的 顺序 局 动 所 有 的 service 容 肴 。 当 然 ， 这 种 情况 无 法 应 对 环 式 依赖 。 


17.4 Compose 评 价 


Compose 的 存在 非常 好 地 缓解 了 用 户 部 署 与 管理 容器 的 痛 点 。 
首先 ，Compose 的 存在 使 得 用 户 无 须 再 录 信 元 长 的 命令 行 命令 , 其 
次 还 扩 宽 了 容器 的 部 署 范 畴 : 从 命令 行 的 单 容 器 部 署 到 Compose 的 


17.4.1 Compose 单 机 能 


Compose 带 来 的 益处 显而易见 ， 那 是 否 意 味 着 Compose 可 以 适 
用 于 Docker 容 颖 部 署 的 所 有 场景 呢 ? 答案 自然 是 否定 的 。 目 前 而 言 ， 
Compose 带 来 的 是 单机 的 便利 ， 面 对 跨 宿主 机 的 容器 部 署 与 管理 ， 
Compose 的 能 力 依然 注 弱 。 同 时 ，Compose 在 单机 上 也 并 非 可 以 完 
成 所 有 的 工作 。 


Compose 的 单机 部 著 管 理 能 力 强大 却 并 非 完 整 。 这 主要 体现 在 
以 下 两 方面 。 


首先 在 架构 上 ,如 前 所 述 ,Compose 的 能 力 会 受 限于 两 个 方 
面 : 自身 的 设计 理念 以 及 dockerpy 对 Docker API 支 持 的 完整 程度 。 
既然 Compose 定 位 为 Docker 容 希 的 部 著 工 具 ， 那 么 只 要 自足 于 这 个 
理念 ， 它 就 不 可 能 支持 所 有 的 Docker API 接 口 ， 人 否则 从 功能 上 将 会 变 
得 类 似 于 第 二 个 dockerpy。 然 而 ,既然 Compose 中 包 狂 了 service 
的 概念 ， 那 么 除了 查看 的 service 的 状态 之 外 ， 更 为 细致 的 情况 下 还 
应 该 能 够 查看 service 的 资源 使 用 情况 。 这 个 方面 , Compose 目 前 还 
没有 集成 ， 毕 竟 docker stats 命 令 在 Docker 1.5.0 版 本 时 才 支 持 ， 
Compose 对 这 些 API 的 支持 显得 有 些 滞后 , dockerpy 的 使 用 也 是 造 
成 这 类 问题 的 重要 原因 。 


其 次 在 使 用 上 ，Compose 的 自动 化 部 署 并 不 意味 着 可 以 完全 蔡 
代 手 动 管理 。 还 以 容器 依赖 为 例 ,虽然 Compose 目 前 支持 判断 容器 
间 的 依赖 ， 并 生成 合理 无 冲突 的 执行 顺序 ,但 是 这 样 的 执行 顺序 ， 仅 
仅 在 时 序 上 有 区 分 ， 并 未 在 容 问 应 用 的 逻辑 上 区 分 。 例 如 ， 容 器 A 为 
一 个 Web 应 用 ， 依 赖 于 容 背 B 这 个 数据 库 ， 配 置 文件 service A 的 
links 参 数 指明 了 service B， 则 Compose 会 在 容 希 B 局 动 完成 之 后 册 
局 动容 器 A。 这 看 似 合理 ， 实 则 不 然 。 对 于 容 硕 A 而 言 ， 应 用 程序 需要 
创建 到 数据 库 的 连接 ,一旦 失败 ， 它 可 能 直接 退出 。 而 数据 库容 器 B 
的 启动 需要 一 个 过 程 ， 只 要 dockerinit 进 程 开 始 执行 ，Docker 
Daemon 均 会 认为 该 容 需 已 经 正常 启动, 故 Compose 通 过 Docker 
Client( docker-py) 也 会 认为 容 毁 B 已 经 启动， 从 而 立即 局 动容 硕 
A。 由 于 此 时 容器 B 中 的 数据 库 应 用 仍 需 要 完成 初始 化 ,直至 最 终 数 据 
库 服务 引擎 完全 启动 之 后 ， 才 能 监听 特定 端口 ， 接 受 外 界 应 用 的 连 
接 。B 容 疮 需要 一 定时 间 来 完成 这 个 阶段 ， 而 Docker Daemon 不 会 
理会 容 需 内 部 的 应 用 逻辑 ， 直接 认为 容 痊 局 动 完毕 ,最 终 Web 应 用 A 
无 法 连接 B 中 的 数据 库 服 务 ， 自 然 会 异常 退出 。 总 的 来 说 ，Compose 
还 是 立足 于 容器 层 的 部 署 ， 并 不 涉及 容器 内 部 应 用 层 的 逻辑 。 而 手动 
部 署 的 方式 ， 则 可 以 在 容器 部 署 完 毕 时 ， 人 为 测试 容 颖 内 部 应 用 程序 
的 状态 ， 从 而 以 此 为 依据 ， 确定 是 否 部 闭 受 依赖 的 容 奖 。 


17.4.2 Compose 跨 节点 能 力 


Docker 容 器 跨 主机 部 署 的 需求 正 逐 步 增 大 ， 稍 令 人 失望 的 是 ， 
Compose 目 前 在 这 方面 的 功能 依旧 不 令 人 满意 。 实 际 应 用 场景 下 ， 
Docker 用 户 往往 希望 将 不 同类 型 的 容 怖 部 闭 在 不 同 的 Docker 节 点 
上 ， 满足 负载 、 安 全 、 资 源 利 用 等 多 方面 的 考虑 。 虽 然 Compose 目 
前 不 具备 这 样 的 能 力 ， 但 并 不 意味 着 Docker 会 放弃 这 方面 的 市 场 。 


17.4.3 Compose 与 Swarm 


Docker 容 希 跨 节点 部 署 方案 的 发 展 ， 用 “需求 决定 方向 "来 形容 
再 准 确 不 过 。 目前 ，Docker 正 在 酝酿 着 Compose 与 Swarm 的 深度 
结合 , 目标 是 : 使 用 户 在 一 个 Swarm 集群 上 运行 Compose 来 部 闭 容 
肴 ， 效 果 和 在 单机 上 使 用 Compose 完 全 一 致 。 


先 分 析 跨 节点 容 问 没有 依赖 的 情况 。 容 痪 之 间 一 旦 没有 依赖 ， 容 
妖 对 自身 所 处 的 节点 位 置 也 就 没有 太 多 需求 。 这 种 情况 下 ,理论 上 ， 
Compose 完 全 可 以 通过 Swarm 的 label 环 境 变量 ， 将 容器 与 满足 条 件 
的 Docker Node 联 系 在 一 起 ; 同时 也 可 以 通过 环境 变量 affinity , 使 
几 个 容器 部 署 在 同一 个 Docker Node 上 或 者 避免 在 同一 个 Docker 
Node 上 . 


再 研究 跨 节点 容 莫 存在 依赖 的 情况 。 跨 节点 容 右 有 依赖 ,第 一 个 
需要 解决 的 问题 是 跨 节点 容 益 的 通信 能 力 。 而 在 Docker 的 范畴 内 ， 如 
果 不 借助 其 他 工具 ， 跨 节点 容 冀 的 通信 目 前 还 没有 很 好 的 支持 。 

此 ,如 links、volumes from、net : container 等 容 闫 依赖 的 情 
况 ， 下 一 版 本 的 Compose 还 会 默认 将 相应 的 容 怖 在 同一 个 主机 上 部 


着 运行 。 


17.5 总结 


本 章 从 Compose 的 历史 与 定位 入 手 ， 随 后 简单 分 析 架 构 设 计 与 
内 部 实现 ， 最 后 评价 了 Compose 在 容器 部 署 方面 的 能 


Compose 的 诞生 ， 并 不 是 为 了 解决 一 切 部 闭 问 题 。 如 有 果 信服 这 
一 点 ， 那 么 研究 Compose 的 应 用 场景 就 变 得 极为 有 价值 。 什 么 样 的 
场景 下 ， 可 以 借助 Compose 发 挥 自动 化 部 署 的 魅力 ， 什 么 样 的 场景 
下 ，Compose 并 不 能 满足 需求 ， 而 需要 用 户 自行 开发 工具 进行 部 著 
与 管理 ， 才 是 在 Docker 容 闫 部 著 与 管理 领域 值得 深究 的 话题 。 
Docker 生 态 圈 仍 需要 不 断 地 发 展 ， 在 容 兹 缺乏 部 著 工 具 方 面 ， 
Compose 仍 然 会 处 于 一 枝 独 秀 的 地 位 。 清 楚 Compose 的 原理 ， 对 于 
Compose 的 运用 定 会 有 很 大 的 帮助 。 


